This is the fourth article in our series about essentials for developing R&D applications — the seemingly small things that are easy to overlook but make your project go much more smoothly. Be sure to check out our articles on documentation, repeatability, and testing.
A development pipeline automates your testing process and gives your app the best opportunity to deploy successfully. There are simply some tasks that are better for computers to do. Humans are fallible and can take longer to accomplish rudimentary tasks.
Besides, if you could set up your testing process once upfront, wouldn’t you want to save that time and cost down the road?
What is being automated?
Automated testing and continuous integration are essential components of using a development pipeline to optimize your testing process and free up your team’s time so they can focus on tasks that make sense for humans to complete. It means that the same thing is going to happen the same way every time because the deployment pipeline is programmed to automate the process. It can be used in most applications and actions, including testing, reprovisioning, and even managing DNS records.
Automation is important for the dev process because it’s increasingly complex. There are parts that make sense for people to perform, and there are parts that make sense to be automated. But with the testing process being integral to your app’s success, it’s worth the time to optimize every step of the way.
It starts with getting your code to a state that you feel is ready in some capacity. You might want to push it up, merge it somewhere, or create a pull request that somebody reviews. It makes sense for these stages to automatically kick off work at those stages without somebody needing to initiate the process.
Each pipeline has its own version of configurations, all based on how you write them. You write the process for it to follow and the triggers that tell it when to start the next task. It follows the build process that you set up and performs the tasks that you tell it to perform.
Here are some sample pipeline stages:
- Unit tests. These can run quickly. If an error is detected, the build fails out and the process can stop before running the more complex, time-intensive build stages.
- End-to-end tests. If the unit tests check out, you can move on to the more comprehensive tests. If this stage fails, it’s easy to inspect the logs, go back, and look at the particular part of the build that was triggered to see the root cause without having to wade through hundreds of lines of code.
- Migration. Code and data can be automatically pushed from dev to QA to prod depending on the triggers that you set up.
- Provisioning. Automated environment provisioning can allow teams to configure test environments once and have them stand up the same way every time.
The Benefit of Time
Some teams create a process with different triggers at different stages. A pipeline is not just about doing one thing at one stage. It can save time at any point. The manual actions can be lightweight tasks that don’t require a lot of time.
An initial build stage for your pipeline can be a combination of automation and manual actions. You can start by testing for basic functionality and then automatically move to the dev stage and set up the app on a dev server. At that point in the dev environment, it might make sense to only run unit tests before manually triggering a move to the next step in the process. At any point, you can configure triggers that require human action, leaving the rest for the pipeline to complete on its own.
Manual actions should also be strategic to maximize time. For instance, when you’re ready to move to QA, you might want to hand it over to your validation team. Your process might be for a human to hit “approve,” then the pipeline moves the code from dev to QA, where you run your full suite of tests. But you don’t want to hand it to your validation team until you know that it does everything you thought it was supposed to do. Why waste the validation team’s time on something that breaks?
Customizable Workflow Options
Every organization has different needs, and every application has a different structure and workflow. Some applications are regulated; some are not. You need to understand the needs of the business and the application so you can answer what it is at a high level and what problems it’s solving. Automation is highly configurable and context-dependent, but it’s flexible enough that you can set it up to meet your customized needs.
Maybe your value proposition to your customers is that you’re constantly updating, so they’re constantly getting the newest version of the app. If that’s the case, you don’t really want to slow down the process with humans hitting the “approve” button for a low-stakes application, especially if you’re emphasizing rapid release development and need to churn out new code as soon as it’s ready. Maybe you want to get a lot of regulatory validation stages out of the way, in which case you just push your code, it runs the tests, and if the tests pass, it automatically goes into production.
Either way, the goal is to get as much human interaction out of the way as possible because that’s a barrier to what’s valuable for your company. Deployment pipelines allow you to set whatever stages are appropriate for you. You can run whatever things at whatever stages that make sense for your team. Regardless of the configuration, it’s lean, fast, and catches everything.
Very Few Downsides
There are very few downsides to automation because you’re not adding any extra steps. The tasks that you’re setting it up to automate are tasks that you’d be doing manually anyway. If you’re setting up a test suite, you’d be writing the tests. If you’re trying to deploy to new environments, you’d be logging into the server and configuring it manually. It does require upfront time, but it’s more than offset by the time and headaches that you save during the life cycle of the project.
One potential downside is that you’re supporting one more piece of technology. Anytime you add to a tech stack, it’s another factor to manage for security attacks and breaches. Like any software tool, your pipeline will have new releases that you need to keep up to date. But that’s the nature of any tool that you integrate. If it has value, you add it and then you take on the necessary risks of maintaining it.
If you’re looking to avoid the time or maintenance, there are companies that manage pipelines for you. Instead of standing up your own server, you can use a cloud-based service where you configure on their servers, and they keep everything up to date for you. While you will pay a premium for these services, they can save you the time and hassle of training or hiring the skills needed to manage your pipeline.
Just like with best practices for documentation, repeatability, and testing, automation requires more planning and work upfront but pays dividends throughout the development process. And with app requirements becoming more complex everyday, it pays to incorporate these approaches into a holistic process so you can give yourself the best chance of success.
Justin Bantuelle balances the responsibilities of both the Chief Operating Officer and the Web Technology Director after having worked with Health Connective for more than a dozen years. Justin regularly leads the cross-disciplinary teams in building out and updating applications for Fortune 500 companies.
Justin keeps his technical abilities sharp by contributing to an eclectic mix of open-source and personal projects on Github.
Jared Johnson
Jared builds innovative healthcare brands through digital strategy and engaging content that turns heads. He is a keynote speaker, prolific content creator, host of the Healthcare Rap podcast and author of Connect the Docs: Put Digital Health Into Practice.