Automatically Building Changed LANSA Objects
Firstly, you will require a separate LANSA installation for building your LANSA objects for deployment. LANSA refers to this as the Build Machine, though it may co-exist with other LANSA installations on the same machine. The main requirement is that the machine will always be powered up, ready to build any changes submitted to the GitLab source code repository.
1. Install Visual LANSA as you have done for the developers previously.
2. Setup a GitLab Runner to pull the source code from the source code repo when a change is committed to your branch. Note that this is NOT the same repo that's being used to deploy the LANSA compiled objects to your target system.
3. Configure the Visual LANSA IDE so that it will automatically compile source code when it changes:
4. Create a gitlab-ci.yml file in the root directory of the source code repository. You may base it on the one used for the distribution repo. As this is source code and all we need to do is pull the git repo, the before_script and after_script are not required.
5. Keep the IDE running. When changes are pushed to the source code repo origin they will be automatically pulled into the IDE.
6. When you want to update your test Target System, 11.7.17 Deploy Your Application changes manually with the click of a button from the Build Machine's Visual LANSA IDE.
Altering the Git Reference that is being watched
The registry setting HKLM\Software\LANSA\APP1\ENG\GITREPOBRANCH on the target system controls which git reference is being watched by the GitLab Runner. By default, it is set to master. You may specify either a branch or a tag. The registry setting is created when you 11.7.11 Set up the Target system and it may also be manually modified
If you specify a branch other than master, then The .gitlab-ci.yml file needs modifying in your development environment. It is deployed along with the rest of the application. In the deploy_branch_job section and the validate_branch_job section, change the only value and the tags value to the branch you want to watch:
If you specify a tag there is a further step that is required. The .gitlab-ci.yml file needs modifying. In the deploy_tag_job section and the validate_tag_job section, change the only value and the tags value to the tag you want to watch:
You will also need to add the new values for the tags attribute when you 11.7.15 Install the GitLab Runner on the Target system. If this is not done, the job will become stuck.
Fine Tuning the Default Settings
The default gitlab-ci.yml file makes it easier to get it running and demonstrates different options, but it may be doing more than you need. For example, there is a test-tag defined as well as deploying a master branch. Usually master is deployed into the test environment. So the test-tag is unnecessary.
Edit the gitlab-ci.yml file and remove the jobs named validate_test_job and deploy_test-tag_job. And also remove the test-tag from the Runner installation.
Introducing a Production Target System
The 11.5 Setup for Test & Production Systems GitLab (single Target instance) does not have a production Target System. Whether the git reference deployed to it is master, test-tag or prod-tag, it will install into the same application configuration. Its just for demonstration purposes.
Firstly, when setting up the first Target System which will be your test system, 11.7.15 Install the GitLab Runner on the Target system specifying just master in the tag-list parameter. If you've already installed it with the defaults, go to the GitLab User Interface and change the Runner configuration so that the Tags parameter = master
Secondly, setup a similar system using 11.7.11 Set up the Target system and when running the AutomateDeploymentTarget.ps1 script, specify prod-tag for the app1branch parameter. Then 11.7.15 Install the GitLab Runner on the Target system specifying prod-tag for the tag-list parameter.
Lastly, fine tune the gitlab-ci.yml to remove the test-tag jobs as described above. Until this is done the pipeline will report a status of stuck, because test-tag is not assigned to any Runner.
Deploying to a Production Target System
Deploying to a production Target System is an action applied directly to the git repo. This example tags the master branch with test-tag. Then that is pushed to the origin.
git update-ref refs/tags/test-tag master
git push --tags --force
To tag a different commit use another git treeish reference like another branch or the commit reference itself. The push is forced because for the second and subsequent tagging, the tag will already exist and this will cause it to be overwritten.
Deploying to Target Systems in a Scalable Stack
You may have a need to deploy an application update to multiple Target Systems. Now this will only work when the Target Systems are fixed. If instead your application is running on a Scalable stack, where machines may be created and terminated in response to load, this cannot be used. You would need to use 11.3 Setup for Test & Production Systems (Target is a LANSA Stack in AWS) .
Each Target System will have its own Runner installed. A restriction of gitlab is that only one Runner will be run when a commit is pushed to the git repository. And that Runner will be the first one that will accept the commit's reference. A Runner may be configured to only use a specific git tag. So this implies that a commit of a separate tag will be required for each Target System that needs to be deployed to.