What are the hallmarks of a quality software development team?  What attributes stand out from software which gives it the feeling of quality?  These questions and many more, lead to the seemingly elusive quality answer.  Certainly, answers to these quality questions have found themselves entrenched in today’s modern software development life cycle process, however, lm continually presented with quality challenges in all projects which l have been fortunate to be a part of.

Throughout my career, l have seen many quality processes and patterns, all with great intentions, both succeed and fail.  Some processes have been too strict and focussed on impractical code coverage targets, whilst others were focused on minimal unit testing but strong focus on integration testing.  Some programs embraced automation, others rejected it.  Coupled with the heterogeneous and diverse business domains, it can be very difficult to select and accept quality patterns as each of them present their own unique challenges to the quality problem.

One thing that l have proven irrefutable is that repeatability is a key enabler of quality.  Repeatability is, after all, the critical component of the Scientific Method which has roots from the past times of Galileo.  Repeatability reinforces the strength of observation, and observation allows identification of patterns, facilitating classification, behavioural analysis and many other exploitable scientific methods of analysis. Repeatability in software development is also a critical dimension in quality assurance. Any process that is automated is highly repeatable and precise, leaving no room for error. This is why computers were created in the first place! However small a task, automation can add significant value to the overall quality dimensions of the system.

On a macro scale, teams within a program will have a number of concerns which they provide services for. For example, the environments or infrastructure teams will build and maintain all environments during the project. They will ensure deployments are executed to the target environments and availability targets of the environments under-management are maintained. The environments team could benefit from an automated deployment system, which is developed to ensure consistency in configuration and deployments. Again, repeatability in deployments increases the quality of the deployments and manifests into higher application availability times and lowers defects relating to environment misconfigurations.

Until now, l’ve described and illustrated that repeatability can increase the quality of deployments if facilitated through an automation framework. This approach is not only relevant for the environments team, and a more holistic approach to automation is required to ensure all facets of the SDLC benefit from the quality enablers of repeatability. This is the task of the Build Pipeline.

The build pipeline has cross-cutting concerns which define the processes for all technology teams in the SDLC. Primarily focussing on development, build engineering and environments teams, the build pipeline formalises and provides clarity into the software development and release processes of the program. Each of the development, build engineering and environments teams will assume custodianship of a portion of the build pipeline to enable the end-to-end artefact creation and assurance process.

Figure 1 - The Build Pipeline

The build pipeline begins with the developers local build. Here, the developer will execute unit testing for the purposes of check-in. Once verified, the process is repeated on the Continuous Integration server, where an additional deployment and integration test cycle is executed. Once verified, the build engineering team will deploy the application into a deployment test environment and reverify. Finally, the environment team will take the, now highly verified software artifacts, and fan-out the deployments into all downstream environments, albeit, System Integration Testing, User Acceptance Testing, even, Production. One key point to mention here, the verification processes in the build pipeline will serve as a quality contract between the teams. For example, the build engineering teams will assert the applications units and integration’s are tested (through unit and integration testing performed in both development and continuous integration) and fail the pipeline operation if this contract is broken.

Realising the build pipeline requires diligence, commitment, collaboration and attention to detail. Once employed, the build pipeline has a proven quality yield that reduces cost through shorter testing cycles and reduced defect numbers. Furthermore, consistent and repeatable deployments through automation will promote the consistency and fault-free environment configurations. Sure, there are upfront costs associated in establishing the build pipeline, however, ignoring the need for one and assuming quality is achievable through our novel methods of the past, have time and time again, proven to be a false economy.