Are you currently using a DevOps pipeline, or moving that direction? Are you looking to integrate testing into the release pipeline? In this article, we’ll briefly discuss DevOps pipelines and give some hints on how you can test in such an environment.
As you participate in the never-ending dance of software development and releases, you’ve probably come across the term “DevOps.” Though it sounds like an elite team of special operatives, the portmanteau is more accurately described as a movement to blur the lines between the traditionally-siloed worlds of development and operations.
In an on-premise software-deployment environment, isolating development and operations has made sense. Operations can focus on releasing the software to the appropriate customer through a medium that users can consume. The developers are 100% dedicated to adding new features and making sure they don’t break the build, and they don’t need to worry about the details and demands of delivering to individual customers.
Yet software is increasingly moving “to the cloud.” With cloud apps and services being deployed to locations hosted by software companies (rather than users), the load of operations is eased. Simultaneously, this movement is eroding the argument that development and operations should continue to be siloed.
“DevOps pipelines” are a powerful tool when uniting the two functions. With the adoption of continuous integration/continuous deployment (CI/CD) with tools such as Jenkins, Travis CI, Gradle, and Bamboo, you can put together a sturdy, reliable pipeline to handle everything from initial build to release. Developers can now push to a code repository and then watch an entirely automated process release that code into your desired environment.
If the software-release process is handled by an automated pipeline, is there still the opportunity to test the code before it’s released into the wild? Do I still need testers? Absolutely! Adopting a pipeline does not mean software testing should be sacrificed to streamline the release process. The very basis of DevOps pipelines is to make the release process reliable and easily repeatable while reducing the chances of errors, delays, and miscommunication.
All of that contributes to higher quality products, right? New or existing automated tests can be easily and smoothly integrated into the pipeline. Unit tests, smoke tests, and regression suites can all be run as part of a release pipeline. The testing is not limited to API tests, either. CI tools such as Jenkins or third-party testing platforms like Mabl can run your UI tests in “headless mode” to avoid interrupting team members’ work whenever the pipeline runs. “Continuous testing” is a significant opportunity with CI/CD.
Let’s walk through a sample scenario. Say several developers have reviewed and approved a code merge to the develop-branch of a code repository. Once the code is merged, the CI/CD tool picks up the changes in the code repository and tells the build server to build the code. If the build is successful, the code is ready to be deployed by another tool. Unit tests (provided by the developers) should be run by the build server as a sanity check. Then, a suite of automated software tests can be kicked off against the successful build as a further check that the code changes have not broken existing features. If any of these steps fail, the pipeline will notify the responsible parties that it’s a breaking build, and deployment is terminated. A successful run will result in deployment to the dev environment.
The scenario above describes only one potential setup. The multitude and variety of available tools allow for incredible flexibility! If manual tests are required, the pipeline can be configured to build the code and then wait until the appropriate user approves the deployment.
Does this defeat the point of using a pipeline? Not at all! The pipeline keeps all of the steps in order, and any part that should be automated in your specific system can be automated. Steps won’t be forgotten or completed out of order. Logs and results are kept in the pipeline for future reference and easy visibility into the status of releases.
You could certainly begin by compiling a pipeline from multiple tools. Many of the individual tools have excellent documentation with notes on how to integrate with other components. If you are new to creating a pipeline, however, we’d recommend checking out GitLab. It is a single tool that can handle source code management, continuous-integration/continuous-delivery, builds, and releases.
With GitLab, your pipeline can be built & managed in a single place. Your software can be tested on the pipeline using your automated test suites stored in GitLab, or by running a command to kick off tests living somewhere else. The source code management is based in Git and is very similar to GitHub, with one prominent difference being the use of “merge requests” rather than “pull requests.” Same basic concept, just different terminology.
Another popular CI/CD tool is Jenkins, an established and well-supported automation server. Like GitLab, Jenkins provides a UI for pipeline dashboards and interaction. Jenkins, however, is not an all-in-one CI/CD solution. While GitLab hosts the resources it uses in the pipeline, Jenkins is more of a coordinator that calls different pieces of your pipeline from wherever they are hosted. It is an exceedingly useful and time-tested tool for scenarios where you want to utilize several different platforms in one pipeline. Jenkins can be configured to build, test, and deploy code once it is pushed to a repository.
As support for DevOps continues to grow, so does the number of available tools for adding automated tests into your pipeline. A well-built pipeline is incredibly flexible and should never require teams to reduce software testing, even if some of that testing is manual. Tools such as GitLab and Jenkins provide an excellent starting place for building a sturdy software-release pipeline as you begin your DevOps journey. So, go ahead. Put on those coveralls and grab your wrench. It’s time to build your software release pipeline and join the DevOps movement.
And if you’re struggling with where to start or need assistance, don’t hesitate to get in touch. We’re always here to help!