How Do I Get Started With CI/CD in LabVIEW?
Too many choices can be overwhelming. Where should you invest your energy? Why is the answer CI/CD? and How do you get started?
In my recent interview with Malcolm Myers, he brought up a very important question. Listen to the short clip below and see if you can spot the question.
What is important?
Malcolm asks "Which one should I be doing?" When it comes to writing software, there is so much hype out there about various techniques and tools. Everyone claims that their specific tool, framework, or methodology is essential and the most important. It can be overwhelming. Like most developers, Malcolm wants to improve and advance in his career, but with all the choices out there, it is difficult for him to decide where to focus his efforts.
How Do I Get Started?
Towards the end, Malcolm also says, "I don't even know where to start." These tools and techniques can be complicated and there's often no good starting material out there. So even if you get past the overwhelm of deciding which tool or technique is the most important to learn, you still have to figure out "How do I learn that?"
Why Continous Integration/Continuous Delivery (CI/CD)?
In answer to Malcolm's question about the most important tool or technique, my answer is CI/CD. If you are not currently utilizing CI/CD, you should be. It should be the first thing you implement. Why? CI/CD is the best investment you can make for risk management in your project. Being able to deploy a simple hello world from the very start of a project helps make sure that you are able to build and deploy your app from the very beginning. At that point, you can have confidence that you can quickly and easily deploy any new features. It also addresses two of the most important risks in building software.
Building The Thing Right
Bugs are always a risk with software. CI/CD helps to reduce the consequence of bugs. It gives you the opportunity to catch those problems before they make it to your customers. Hopefully, you are already writing unit tests, but if you aren't, still set up CI/CD first. Leave a placeholder for the tests. It will be much easier to add those later and ensure that they are run consistently. CI/CD also helps you to catch problems with the build, packaging, and deployment process. If you combine this with taking small steps, then those problems become much easier to fix.
Building the Right Thing
A robust CI/CD pipeline also addresses the risk of building the wrong thing. A CI/CD pipeline enables you to immediately push new features out to your clients so that you can get feedback. No more haggling over vague requirements. Take your best shot at building what you think the client wants and immediately give it to them to try out. Then simply ask them "Is this what you really wanted?" A CI/CD pipeline doesn't stop you from building the wrong thing, but it does help you quickly figure out that you built the wrong thing. If you have been taking small steps, then all you have to do is revert back to a previous state in Git and change direction.
How Can I Quickly And Easily Get Started With CI/CD?
The next obvious question is where do I start with CI/CD? CI/CD is complicated in general and even more so with LabVIEW. There are a lot of moving parts. There are also a bunch of choices to make as far as which tools to use. In an effort to encourage everyone in the LabVIEW Community to adopt CI/CD, I have put together a set of simple tools and templates to take some of the guesswork out and to get people up and started sooner.
Getting Started with G-CLI and GitLab CI
The foundation for getting started with CI is being able to automate common LabVIEW tasks from the Command Line Interface (CLI): things like building exes and packages, running unit tests, and applying VIPC files. No matter which CI tool you use, at some point you have to use the CLI to launch some task. To that end, I put together a set of open-source G-CLI tools for common LabVIEW CI tasks and put them up on VIPM, so you can easily install them.
The next step after being able to run CLI commands is to pick a CI solution. I chose GitLab because that is what I typically use. It is free and it is quick and easy to set up an account. It is also one of the less-complicated setups for CI. I put together instructions on how to set up GitLab Runner. I also put together some example yaml files that you can simply drop into your repository, update a few variables and you are ready to go.
More Information
Here is a link to the landing page for the G-CLI tools, which also includes instructions on setting up GitLab Runner and example yaml files. When I get some more free time, I will put together a sample GitLab project to make it even easier.
