In today’s evolving market, labs inevitably need to make changes within their informatics software stack. The greater your lab’s efficiency in making these changes, the easier you’ll be able to keep up with new demands and innovations. How your software environment is set up can make a huge difference in how quickly you can validate new processes and updates to the software before deploying them.
We frequently get called in to help labs design a process to manage code and configuration changes while enabling innovation and regulatory compliance. A critical component of our strategy is to employ tools to bring your configuration and code together under version control. This reduces the process burden for the highly-skilled people on your team.
We’ve talked before about supporting your lab with continuous improvement. In this post, we’ll discuss why an effective continuous improvement strategy of incorporating continuous integration (CI) and continuous deployment (CD) into your software lifecycle — which can be thought of as the lab’s “workflow change pipeline” — can improve your lab’s productivity.
What is a CI/CD pipeline?
A CI/CD pipeline — part of the DevOps methodology — is a cyclical workflow for streamlining your software development releases. In a laboratory context, software releases are often tied to the introduction of new assays or assay revisions.
- Pipeline: An assemblage of infrastructure supporting software development, requirements management, and automated testing processes as applied to a system and its series of environments (starting with a Development environment, transitioning through a Test and/or Staging environment, and culminating in a Production environment).
- Continuous Integration (CI): Code changes are merged into a shared repository as often as possible to rapidly surface and ideally avoid potential integration issues with other collaborators.
- Continuous Deployment (CD): Code changes that pass all stages and tests built into the pipeline are automatically available to be deployed.
Common software development terminology
For lab staff who aren’t familiar with the standard software environments, here’s a quick overview of the common ones that are relevant to CI/CD.
| Environment | Description |
| Development | The location where new features (such as LIMS workflows or instrument/system integrations) are actively developed. |
| Test | The location where newly-developed features are tested. If the test fails, software development continues in the Development environment; if it passes, the software is promoted to the Staging environment. |
| Staging | The location where software changes are validated before they are promoted to the Production environment. The Staging environment should mirror Production in every way except for the new changes to be tested.
Note that while the Test environment is primarily used for testing piecemeal changes or updates, Staging is for finalizing a set of changes together in a realistic environment, usually with the option to test with lab instrumentation. |
| Production | The location where software and other products are put into operation for their intended uses by end users. In the lab, this is the software environment where patient samples are actively processed. |
At Semaphore, our best practice entails the use of a minimum of three environments (Development, Test or Staging, and Production) with defined test plans between each environment to ensure that no errors are introduced into a Production environment. After a successful deployment to Production, we copy the new live Production environment into the starting environments (Development, Test, Staging). This ensures that we are always starting from an exact duplicate of the current Production environment when developing.
Software developers also commonly talk about the Software Development Lifecycle (SDLC). This is an industry-standard process for developing software that is high quality and meets business requirements. You can apply CI/CD to key stages of the SDLC.
A sample SDLC framework with CI/CD
In the clinical lab sector, labs generally do not automatically deploy releases on a schedule or based on a particular frequency. They might use CD to deploy changes to the Test environment, but when it comes to Production, they tend to deploy updates infrequently and only after rigorous additional testing.
In part that’s because lab software updates, unlike common consumer software like social media apps, must be validated and verified for performance prior to release. Furthermore, as part of the total testing process, lab staff need to be thoroughly trained so they are ready for the new release. That means managing updates through a formal change management process.
Here’s the SDLC framework we use at Semaphore, and recommend to our clients, with CI/CD incorporated:
- Generate requirements through analysis. We hold meetings to establish detailed requirements and achieve stakeholder consensus on each.
- Promote granular requirements to the approved backlog of work.
- Create estimates for development tasks based on requirements.
- Assign tasks to Sprints. Within a Sprint, we develop the software, peer-review each task, run automated tests to identify any problems, and commit the task code to the master codebase. This is where CI occurs.
- Bundle the software for completed tasks into a full software deliverable — the release candidate.
- Promote the software to the Test environment (this is the most likely aspect to be covered by CD) and conduct user acceptance testing.
- Write validation documentation.
- Promote the software to the Staging environment and run pre-production tests with real samples.
- Deploy the software to the Production environment.
CI/CD tools and other considerations
For labs that want to adopt CI/CD, there are a number of tools that can help you. In our experience, GitHub Actions is an easy way to get started, but it doesn’t have the flexibility of dedicated CI tools, which is why we recommend you choose one of the following:
When choosing a CI tool, consider factors such as how it will interact with the team’s processes and whether CI configuration is part of the code repository (most, but not all, CI solutions support this). Setup shouldn’t require a lot of complex configuration. In addition, we believe the CI tool should support most common build tools to the point where if your code is well set up and structured, the CI tool will run the build and perform the testing automatically after every submitted change.
Note that this post lists some of the differences between GitHub Actions and GitLab CI, if you’d like to learn more.
We also recommend being mindful of overbuilding the pipeline. This can lead to unnecessary overhead, so we always suggest starting with a list of the functionality you need (requirements). Once those are documented, do the same for access control. Consider who will maintain the pipeline, who will be impacted by changes or outages, and who needs access to the settings. Then, build to these requirements.
Why you should implement a CI/CD pipeline
The main reason why we recommend all labs implement CI/CD within the software development process is to remove friction and enable your workflow change pipeline to flow smoothly. CI/CD can help with testing new code, preventing bugs that could cause serious issues if they were to make it into the release, thus reducing the need for human intervention later. It can also help you shorten the cycle time for deploying changes, so you can move updates into production faster.
Furthermore, it can help you standardize your software development practices and optimize planning for new or updated features. A standardized process lets you implement new changes the same way every time, which enables a more reliable flow. Lastly, it facilitates collaboration among team members, which makes it easier to deliver the software product within a specific time frame.
