Tierney - stock.adobe.com
Automate these DevOps tasks for maximum productivity
DevOps is hard work, but only upfront. The goal -- once teams build a pipeline and set up automation -- is to stand aside and watch the builds flow through.
There are many ways to explain what DevOps is. One of the best ways is to break it down to its most basic parts: no tool sets, no languages, just the foundation on which to build a DevOps practice.
First and foremost is the code, which is stored in a version-controlled repository. However, that code also needs an environment in which to run. The steps required to move code from the repository to that environment -- as well as the triggers that run those steps -- are also fundamental to DevOps.
This article covers how to automate DevOps processes using a couple of examples with PowerShell modules and infrastructure-as-code deployments with Terraform and Git.
Automate DevOps build and release steps
From a development standpoint, code goes through a number of standard steps that vary in complexity depending on the language and purpose of the repository. For simplicity, we'll focus on two major steps: build and release.
The steps required to build a PowerShell script module -- write code, merge, test, then package it as an artifact -- are easily automated. For the PowerShell script module -- a PowerShell module built in PowerShell, rather than in C# -- pull all the functions into a module file; build a manifest; run Pester tests, including PSScriptAnalyzer tests, to verify that the input commands executed correctly; and then, if all of the tests pass, package the module and publish it to an artifact repository. Publish public modules to the PowerShell Gallery. All these steps can be written in PowerShell directly, either with custom scripts or a standardized build process, such as Invoke-Build or psake. Since you can write everything in PowerShell, the build could also run locally on a development machine. However, it won't automatically trigger like it would in a DevOps platform.
This example skips the release of the PowerShell module because the code is only being packaged and published to an artifact repository. There are no environments in this scenario. To discuss releases, let's look at a Terraform infrastructure-as-code example.
Terraform uses templates to define resource configurations in modules. To pull in dependencies, use automation to collect the modules and place them in the config file's modules folder during the build process. Next, use the Terraform validate command to verify the config is properly formatted. The build should halt if this fails. Once both previous tasks are complete, zip everything up and publish the file to be collected in the release.
The release step is very important for infrastructure-as-code deployments -- especially if the deployment supports a larger software platform. Therefore, admins typically release to non-production environments before releasing to end users. This is where the development, testing, staging and production environments come into play. All the development happens in the development environment; QA staff runs tests in the testing environment; any final tests or new feature demos run in the staging environment; and end users access the platform in the production environment.
Set up automation to move the latest version of the Terraform config to each environment after any automated tests or QA tester approvals are complete. In smaller shops, these might come from only a couple people.
DevOps automation triggers
Now that we know which DevOps steps to automate, the next stage is to determine when to automate them. For this example, we will use Git, an open source distributed code management and version control system.
A pull request -- a notification that changes were made to the code -- is one of the key advantages of branching, a software management practice that creates copies of code to maintain the original's stability while IT staff make isolated changes to it. A pull request provides an event to run a test build on the branch before pulling it into the master branch. You can tag branches as pull request builds and choose whether to publish them. Run a build on the pull request branch to test whether the code will build successfully on the master branch. If it doesn't build successfully, fix any issues before merging code to the master branch. Code projects with multiple collaborators often require the build to pass before the code merges into the master branch. This is true for both the PowerShell module example and the infrastructure-as-code example above.
After the pull request is approved -- preferably by the automated means covered above -- the code is merged into the master branch, which provides another useful automation trigger. First, the master branch will build. Unlike in a pull request build, a master branch build publishes the code to the artifact repository with the full target version. IT admins can trigger a release automatically when a master branch builds successfully.
In the infrastructure-as-code example, the master branch build is where the config is deployed to the cloud platform and environment of choice -- development, testing, staging or production.
