The committed use of a continuous delivery pipeline inevitably puts a far greater onus on the software developer than systems that used more traditional methods of moving code into product.
A DevOps approach to software development means software developers must be much more diligent in terms of the unit tests they write, and the test code coverage they provide. With continuous integration and continuous delivery, testing can no longer be an aspect of software development to which the developer simply pays lip service. A project folder containing a set of hastily written unit tests that serve little more purpose than to pass a software development audit is no longer good enough.
Due diligence and the DevOps developer
Of course, being diligent in the tests one writes is an expectation, so developers can’t complain about the rigorous requirement to do their job properly. But quick fixes and fast patches that skip the test phase are a thing of the past when CI and CD is used, as anything untested programatically that goes into production and fails points a finger directly back to the developer who didn’t thoroughly test their software. Unit tests must be well thought out, methodical and extensive.
Successful DevOps developers can take solace in the fact that the burden of assembling a continuous delivery pipleline is not one that falls entirely upon their shoulders. The tooling that has developed within the continuous delivery space is impressive. The CI tools themselves can then hook in to a variety of other tools that help move code through the software development lifecycle. The CI server can read Maven POM files in order to download required libraries and invoke Gradle scripts to perform builds. More importantly, the continuous delivery pipeline will hook into various verification tools that will run test suites. Jenkins and Hudson dominate the continuous integration server space, although there are many competitors, including Concourse CI, which are upping the ante in terms of scalability and the simplicity with which CI and CD pipelines are defined.
DevOps tooling advances
Open source tools such as JUnit and Mockito can to be called upon to run unit tests and mocks. Static code analyzers such as SonarCube or HP’s Fortify will inspect the code and flag and rate the severity of potential bugs, vulnerabilities and just general code smell. DBUnit and H2 are often called upon to stub out a database and allow integration tests to take place within an isolated environment. LoadRunner or Apache Jmeter can be used to ensure the new release can handle peak loads, and results from a performance scanning tool such as XRebel can ensure that there aren’t any outstanding performance issues that need to be addressed. When every test cycle provides the continuous delivery pipeline with a passing grade, new code gets moved into production.
But by removing all of the manual checks, and expecting every red flag to be triggered by a test that has been coded into the system, organizations embracing a DevOps based approach to software development are placing a much greater onus on the shoulders of their software developers by not only making them responsible for the code they write, but also responsible for all of the checkpoints that exist to ensure that only bug free code is put into production. It’s a heavy burden to bare, not to mention a new one for developers who have never worked in a truly DevOps based environment.