Anyone have any ideas on how to generate aimmspack in CI / CD pipelines?

@CarlosOnline , would generating the aimmspack file in git hooks on the local machine and moving that aimmspack file to the desired location on the remote server using your CI/CD pipelines work for you ?

What do you mean by local machine?

We don't want to check in the .aimmspack.

@CarlosOnline 

By local machine, I mean the machine on which a developer makes changes to the source code. Change source code, commit on local machine - trigger a commit-hook to create the .aimmspack file. The developer then pushes his changes (which includes the new .aimmspack file) to the remote server, which will trigger your CI/CD pipelines. 

We are using Azure DevOps, I don’t see commit-hook feature in Azure DevOps.

Hi @CarlosOnline , the idea here is to automate the creation of the aimmspack file in the repo itself (using Git) instead of in the pipelines. So, by the time a pipeline is triggered - the aimmspack file will already be there and your pipeline could contain an action to move this file to the destination location. 

Creation of the .aimmspack file requires the aimms executable and also a license, so it is not possible to have this process part of pipelines which run on remote servers as of now. 

Hooks are a git feature and Azure Repos work with Git or TFVC. Which one are you using ? I would expect TFVC to have an equivalent feature as well. Git - githooks Documentation (git-scm.com)

The workflow is as below

1. AIMMS Developer (with a license) makes changes in the project source code on their computer.
2. Commit their changes with a commit message. 
3. The git hook script is executed and creates the .aimmspack file.
4. Push their changes to the remote server.
5. CI/CD pipeline starts. 

See below example where I configured exportAIMMS.bat as a hook to be run every time I start a commit. As soon as I start the commit process, the exportAIMMS.bat file is executed and it will create the aimmspack of the Model.aimms project. 

We use TortoiseGIT as a UI for git and here’s the configuration. 

All of this will happen client side, on the computer of the person who is making changes to the AIMMS source code. Pipelines will start once they push their changes to the remote server. 

The project and bat file is attached for your reference. 

I also support this feature request for a CI/CD setup and a potential trunk-based development:

• Developer pushes a commit
• Pull Request kicks in a CI step to verify unit tests and successful (aimmspack) build before code review
  • PR for release deploys aimmspack to dev server and stages production deployment until approval
• Changes merged into trunk after code review

Besides having a build server with a valid AIMMS license, there needs to be a service that allows for POST request of aimmspack and application configuration on AIMMS PRO servers.

The unit tests may be carried out locally (via git-hooks) before the PR is opened and can be verified as a part of build policy by checking for AimmsUnit.SUCCEEDED file after making changes. The latter would allow having a light-weight license without any solvers for the build server.

@mohansx, what do you think? If this is reasonable, could this feature be considered to be voted on by the community?

We could also complete all testing and building locally via git-hooks as you suggest but a feature to manage AIMMS PRO applications from the build server will enable the CD step and further UI testing on dev/test server.

No need for voting, we have a REST API for managing PRO on our roadmap already (including publishing and running apps). We also have creating an aimmspack from the command line on our roadmap.

Old topic, but here is a follow up on this topic: