Streamlined Software Release Process
14 December 2020
Introduction
Why do we need to worry about having a release process? The release process to us is the part of the project when you distribute the executable code that enables your customer to run the application you have developed without having all the source code. For those in the LabVIEW world this is building an executable of your source code, in the C# world this is publishing your application files. Having a process for your releases has many benefits such as more easily managing what has been released where and the process being the same for each project. We have recently integrated this into our Continuous Integration (CI) process to further streamline and standardise our approach.
Our Process
Our source code is managed through Git and we structure our branches with master and feature branches. The master is the code base related to what is currently on the customer's site and feature branches are used to develop changes. We use Jenkins for our CI and specifically we utilise Pipelines.
When a feature is complete and ready to release to the customer we create a release branch from the feature branch. The structure and format of the release branch name is important and is used to trigger a different CI process when changes are pushed or a build is started. The Jenkinsfile is where the control over what CI process is executed is defined, an extract below shows how this is setup. When a release has been deployed on site, the release branch is merged into master and the release and feature branches are removed.
The main difference at the moment between a release branch CI process and a regular feature branch is that a NI Package is created. Once created it is transferred to a secure server, which is linked to a NI Package Manager feed. The customer or our team can then update the application on site to the latest release. With this approach the application can easily be rolled back to the previous version if any issues with the release are found. We have used this for our LabVIEW applications and for our C# applications. Using it with C# is not straightforward and requires a deeper understanding of NI Package Manager. Potentially there are better tools to manage C# releases like Docker, we will be adding that to our process development list!
Updating the application from a NI Package Manager feed requires an internet connection, so isn't always possible with all customers. One advantage of using NI Package Manager with an internet connections is that you can easily install all the required dependencies for a package. If you don't have the luxury of an internet connection then you need to take another approach. We had this scenario recently where the application was being deployed to a ruggedised industrial PC with no access to the internet. One option, which is what we went with, is to create an installer using NI Package Builder (shown below)
We have used this in a very simplistic way (we like simple!) and created an installer on the right hand side and then added our NI Package, output from our CI process, to the installer. Right clicking on the installer and selecting 'build package' creates your installer files, similar to those shown below. Each time the NI Package gets updated the package in the installer needs updating and the installer recreated.
We are really keen to automate the creation of the installer, it has been added to our list of improvements, if anyone has done this it would be great to chat! We would love to hear about how you release your code, if we can learn from what you have done, that would be ace!
Back to Blog listings