Frequent and Reliable Software Releases

The sheer complexity of the average enterprise application delivery chain makes collaboration integral to achieving a proficient software release function. Time to market in an increasingly competitive application landscape is critical for businesses. With so many moving parts, a lack of cohesion really can mean the difference between the success and failure of any application development initiative. Not to mention a business dependent on its revenue generating capability. The fundamental premise behind DevOps is that regardless of where in your organisations software release participants sit hierarchically or geographically, they should function as a unified, integrated and cohesive unit.

Continuous Delivery (CD) is itself a DevOps discipline, which paradoxically comprises other DevOps techniques to collectively improve the efficiency of application delivery. Effectively enabling organizations who develop their own software to rapidly, reliably and repeatedly release applications ‘at any time’ - with minimal risk or manual overhead required. While many will debate the true definition of DevOps, few will argue that Continuous Delivery is its most aspired to tenet. Considered by many to be the ultimate DevOps objective, Continuous Delivery is sadly still often deemed a bridge too far for large scale enterprises.

Distributed development teams working in parallel are commonplace amongst enterprises, making version control a complex challenge. Typically a developer looking to work on a particular code base will make a copy from the source code repository. As others working on the same source code submit changes to the repository, the original copy being worked on by the developer fails to reflect the newest version in the repository. This ultimately leads to conflicts and failure when the code is attempted to be reintegrated into the main line. The source has diverged as the code worked on is in effect, different. Such integration issues as a result of version control are so impactful that have actually been known to completely invalidate development work. Regularly requiring a time consuming redo. Consequently, Continuous Integration (CI) remains the primary focus for DevOps aspiring companies.

Going one step further than Continuous Integration, the core principle of CD is that every application change is releasable reliably, efficiently and in an automated fashion. Continuous Delivery is in many respects a philosophical extension of CI combining application build, test and release into a clear promotion path to form a collaborative, delivery pipeline. Unfortunately CI while important is simply not impactful enough to stay ahead in today’s market place. Enterprises can now potentially compete with much smaller, agile and often more innovative companies – leveraging CD to their maximum advantage.

Software Releases Should Be Boring

Continuous Delivery support accelerated application development while reducing risk and cost. Ultimately removing the potential pain that too often comes with releases. Regular deployment of reliable, low-risk releases enables software to be continuously evolved with feedback from end users, market changes and even strategic shifts in enterprise trajectory. CD is implemented in a best practice sense as a delivery pipeline. Development, test, support and operations work together as one team to streamline build, test and release processes. A CD pipeline is formed of a set of jobs which are executed in a predefined sequence - with rapid feedback provided at each stage and defined rules governing progression between the stages.

The CD pipeline fundamentally starts with Devs making changes to source code and ends with deployment of these code changes into Production. CD consists of 3 important practices: Continuous Integration, Build Automation and Test Automation:

Continuous Integration (CI)
The longer that parallel development occurs without integration into the mainline, the more likely issues are to occur. CI is one of the defining principles of Continuous Delivery and attempts to prevent version control issues from occurring by through frequent integration. Developers can avoid integration issues by maintaining a code repository and having everyone commit to a baseline on daily basis. Through more regular integration, developers are able to detect integration errors more quickly and develop reliable software more rapidly.

Build Automation (BA)
Build Automation minimises the effort involved in builds. Every baseline commit must be built to verify that integration has occurred correctly. Hence the build process itself must be fast. With the right tool set, a single command should perform the required integration and build without manual intervention. To streamline and automate compilation and build, it’s important that applications are self-contained. All the files required at runtime must be packaged as a single unit and deployed as a single unit. It is equally important that a release is totally portable. Application code shouldn’t have references to the deployment location itself. The deployment location of the application should be mutually exclusive.

Test Automation (TA)
Equally important to the Continuous Delivery equation is the frequency of testing that occurs in correlation to integration and builds. Running unit tests after a build is equally important to ensuring the stability of code changes. Each and every build should undergo testing and in doing so provides early warning of defects or conflicting changes. In order to test each and every build quickly, this testing process should be an automated one. Although manual testing is an option, it is unlikely to be sufficiently fast enough to realise the potential time saving benefits of a Continuous Delivery approach. Acceptance Tests prior to User Acceptance Testing should also be automated to achieve an efficient CD pipeline.

CD is More Than Just CI, BA and TA

Pre-defined design standards should govern the execution of each of the CD pipelines stages. With the correct DevOps tools, most CD steps are triggered automatically without the need for manual intervention. Feedback at every stage acts as a quality gate, which ensures each change meets the defined quality standards. Unless each and every one of a gates criteria has been met successfully, progression of code to the next CD stage will not occur.

Visibility Across Teams, Throughout Lifecycle
CD tools provide all stakeholders and release management participants with visibility of a release. The particulars of each and every release should be available enterprise wide, with a full audit trail and history throughout its lifecycle. Tool selection is key in this respect – by removing ambiguity.

Self-Service Provisioning
Developers need the ability to ‘spin-up’ (and destroy) entire Dev/Test environments comprising multiple, role defined and configuration managed nodes in an automated fashion. Effective DevOps organisations provide this facility via rights restricted portals with integrated approval. Further including easy definition of complete environmental templates for provisioning.

Source, Version, Artefact and Configuration Control
Application artefacts including source code, configurations and provisioning scripts should be booked into a version control system. It’s integral that any software version can be compiled, configured and deployed from its source code - without needing additional files. Organisations striving for CD must have the facility to check projects out, track changes and commit them in a staged fashion, using their version control or artefact management systems.

TRUNK Based Development
Development should be trunk based meaning all code is part of the same stream. This ensures complete integration of the code line and enables CI. As soon as a new branch is created, the benefits of CI are reduced as it’s no longer possible to completely quality check code. For features with longer development cycles, design principles like feature hiding and feature flags should be used. Retaining the ability to deliver small features and maintain one code line.

Deployment Automation
Automated deployment is critical to a Continuous Delivery pipeline. Automated releases don’t suffer from variability or issues pertaining to human error. Implemented correctly, anyone in the team can deploy software which can be done more frequently. Deployment automation also provides a full audit trail of releases, versioning and roll back mechanisms if required.

Application Intelligence
Application Performance Management solutions while not traditional CD, are an effective ways to prevent code issues from being released. When they exist in pre-production and production, the performance impact of changes can be compared against existing baselines.