Chapter 6. Software Deployments and Delivery

As the Internet of Things increases the number of connected devices, IT operations personnel have been tasked with maintaining the existing scaled infrastructure as well as engineering new and innovative approaches to deliver software without risk. On the other side of the fence, software engineers have also been busy employing new and creative techniques to increase collaboration, control costs, and decrease production deployment failures. These two seemingly equidistant efforts have led to significant advancements in the exciting field of release engineering.

One of the more recent evolutions in release engineering combines traditionally segregated IT and development resources into hybrid cross-functional DevOps teams. DevOps-oriented teams are aimed at bridging the gap between traditional operations personnel, quality assurance engineers, and software engineers, all in an effort to employ modern, delivery practices and streamline the release...

Standardizing build outputs

The build process (especially the packaging and publishing phases) marks a foundational corner stone for automated deployments. For this reason, it is important to understand the basic lifecycle of a typical build process. The aim of the build process is generally to automate the validation of compilation quality of source-controlled assets, automate the creation of viable artifacts, and provide a software product that engineering can potentially hand to the business. While the technology stack may vary across organizations, typical build processes will follow a similar set of automation patterns. Let's look at the basic flow of a generic build process:

1. Obtain a clean copy of the source code from source control.

2. Fetch any dependencies (preferably from an artifact repository).

3. Version stamp any necessary code (may be a pre-compile or post-compile step, depending on the technology stack).

4. Compile the source code and verify syntax.

5. Execute unit tests (unit-based validation...

Implementing a Definitive Media Library

A Definitive Media Library (DML) a term coined by ITIL and often referred to as a DML is recognized as a single source of truth for company software assets, dependencies, and third-party libraries. By nature a DML ensures assets are backed up, checksum verified, and managed appropriately. By implementing an artifact repository, or binary asset management system, that facilitates the aquisition of individually versioned packages, dependencies, or Docker containers, engineering id in effect organizing and showcasing software development outputs, intellectual property, and releases.

This type of solution organizes software assets in a centralized location that automation and the business can consume. An artifact management solution also provides the organization with the tools necessary to create a library of deployable entities and third-party dependencies. An additional benefit of this solution is that most modern DML solutions provide optional license...

Automated deployments

Now that we have a solid understanding of how to prepare a software project for deployment by architecting a package solution and leveraging a DML, we will need to define our delivery system. The most widely accepted approach in modern software build and delivery is to apply a manufacturing assembly-line paradigm to the software-release process. This methodology is prevalent at countless software-engineering organizations and seemingly transcends any specific development paradigms, including agile, lean, or waterfall. It can also be universally applied across numerous technology stacks, including Linux, Windows, Mac, iOS, Android, Embedded, Firmware, and so on.

In an assembly-line approach to software releases, pre-built packages (or containers) flow down the assembly line, are inspected by relevant stakeholders, and are eventually handed to the business for release. Packages will traditionally start in a development environment and pass through various quality-control...

Summary

Today, there are various methods and means to facilitate automated deployments for a software project. Whatever the technology is, we can learn and innovate creative ways to attach that to Jenkins. By attaching our deployments to Jenkins, we can move Jenkins into the realm of an automation orchestration platform and out of the realm of grandma's build tool. Whichever way you decide to implement automated deployments, be sure to try and facilitate the following best practice features:

• Deploying any version of a software solution should be as easy as a button click

• Rolling forward or backward in time should also be a button click

• Maintaining your environmental configurations in code form (infrastructure as code)

In this chapter of Mastering Jenkins we discovered some innovative ways we can approach software delivery and some tricks we can leverage to automate deployments. We learned about packaging, and versioning our tests as well as automation scripts. We covered artifact repositories...