In a previous post, I talked about various ways to earn technical interest. One of those ways was Continuous Integration or CI. I thought I would elaborate a little on the benefits of using CI to automate the boring stuff so you can detect problems early, streamline your process, and stay ahead of the curve.
Automate the boring stuff
An obvious benefit of CI is automating the boring stuff. If you have a VI analyzer test, unit test, or build script that takes a while to run, no one is going to want to just sit there and watch it run. It’- boring. It’s a waste of time. Your developers are likely to either not run them or run them as infrequently as they can get away with. If they do run them regularly their machines are likely tied up. That means they are off doing something else. Hopefully, that something else is productive such as catching up on e-mails and not just browsing youtube or hanging out at the watercooler.
CI allows us to automate those boring tasks to make sure they get done regularly and helps to free up our developer’s machines. All the developer has to do is push to the server, which they are already doing anyway. The server takes care of running everything in the background to avoid tying up the developer’s machine. It will then email the developer if there is a problem.
Detect Problems Early
I used to think that simply the time saved automating the boring stuff was the main benefit of using CI, but I was wrong. The main benefit of using CI is less time spent debugging due to closing the loop.
Allow me to explain. Every code base has bugs. It’s inevitable. Closing the loop is about shortening the time between when a bug is introduced and when it is found. If that time period is large, we have a lot of changes to sort through to figure out which change caused the problem. The older the changes the less likely we are to remember why we made the change in the first place. This process is difficult and costly. Closing the loop means decreasing the
Streamline your process
CI really shines when you pair it with robust branching/merging process such as GitLab Flow. This allows us to take different actions based on the type of commits and which branches they are on. We can create subsets of our unit tests and vi analyzer tests to run on feature branches. We can also carefully choose when we run our build and deploy scripts. This helps us close the loop on feature branches by giving developers quicker feedback. It can also help prequalify merge requests. If the branch jobs don’t pass we can immediately reject the merge request. It also gives us clear goalposts when delegating tasks to other developers. All these benefits help to streamline the development process
Stay ahead of the curve
The LabVIEW community has always lagged behind the traditional text-based programming communities. When I started working with LabVIEW a dozen years ago, source code control (SCC) was not that common within the LabVIEW Community even though it had been widely adopted outside LabVIEW. Now it is simply standard practice. We are currently at that point with CI. The general programming community has already adopted it, and the LabVIEW Community is playing catch up. In the next 5-10 years, CI will become as ubiquitous in the LabVIEW Community as SCC is now.
Now is the time to get a