In the DevOps building blocks tutorial, we identified automation as a useful technique for quickly delivering software and developing collaboration between development and operations. We also discussed other benefits of automated releasing such as risk minimization and reproducibility. In this article, we will focus on what is needed before automation can happen and the implementation of automation.
Technically, a software release refers to integrating teamwork, code compilation, linking and deploying to a target environment. Software release involves infrastructure management, installation and configuration depending on the target environment. The configuration and resources needed by an application make up the environment. The functional perspective of a release is that the functionality required by the user is made available.
In an automated release approach, there are several conditions that need to be met and they are listed below.
- The team members need to be committed to working collaboratively
- Tools such as Jenkins and Maven need to be identified and coordinated with requirements
- Items that are included in the configuration such as database resources, source, and others need to be versioned
- The infrastructure, middleware and dependencies needed to run the application should be clearly stated.
- Continuous integration needs to be applied and there are several things to keep in mind. One, you need to be committed to immediately resolving broken builds.
- A clear definition of a passed test should be put in place
- Broken tests should be put in place and not merely deleted of commented unless there is a justifiable reason
- Code source and different scripts that are used should be integrated
- It is important to have clearly delineated boundaries between version tools such as Git, component repositories tools and package repositories tools such as Yum.
- Avoid including configuration settings into binaries and instead they are specified during deployment or later.
- It is important to maintain similarity in the development and operations environments.
- You need to clearly define a process that is used to incorporate changes to systems that are in deployment.
- Activities that require a lot of time and repetition should be automated
- Designate a single build server where all build activities are done and avoid any build or patching on any other machine other than the build server.
In an automated release, multiple tools, methods, and approaches are used. One of the approaches used in automated deployment is build pipelines. Build pipelines consist of all the steps and dependencies required to build functional software. Below is a partial list of steps that can be included in a pipeline. The number of steps depends on context therefore the list should just be considered a rough guide.
- Software compilation
- Unit testing
- Backing up
- Testing the application is running as expected
- Monitoring after the application has been deployed
- Creating the necessary infrastructure to support the application
- Software packaging
- Preparing the application with the view of getting a release candidate approved
A build pipeline can be considered a representation of the steps that have to be undertaken is software development. You begin with software changes that pass through the pipeline and the end product is the software in production. From a technical perspective, we can think of a pipeline as a way of organizing the build process so that it can pass through multiple automated and manual quality checks.
Another approach used in automated deployment is baselines. A baseline can be considered a review of previous works which can be used as a development foundation.
Another approach used in automated deployment is the practice of sharing version numbers among management, operations and development. DevOps emphasizes the importance of using consistent version numbers across different departments. Version control systems (VCS) promote collaboration between development and operations therefore it is a good idea to use version numbers derived from VCS. The use of VCS revision codes has several advantages which are listed below.
- Creation of revision code is handled by the VCS, which eliminates the need to create scripts that may introduce errors.
- There is uniqueness in the codes created by each VCS
- There is stability in the code created
Another approach in automated deployment is to use common tools between development and operations. JIRA is a reliable defect tracking tool which can be used to track issues that are related to work. DevOps emphasizes the use of one tool to track work issues. Although it is possible to use one tool to track work of development and operations it is a bit challenging to track their processes. A possible solution to this challenge is work units that are common in either which go on to become a task approach.
Another approach that can be used in automated deployment is the creation of scripts that automatically update databases. When considering databases there is a challenge in automating deployment because there may be differences in the database structure between different versions. Therefore, there is a need to put in place a mechanism that supports database evolution while at the same time preserving the database structure. Some tasks that are common when applying database changes are listed below.
- Placing the database structure and changes in a CVS
- Creating database scripts that can be used to switch to the previous or next database version
In this tutorial, we began by reviewing the benefits of automated deployment that were covered in another article. A definition of the technical and functional perspectives of a release was provided. We enumerated requirements that need to be put in place before automated deployment can be implemented. Finally, we discussed the approaches that are used in automated deployment.