A deployment pipeline keeps infrastructure ducks in their rows
IT infrastructure is difficult to get right. Whether to stand up a test/dev server or deploy a new app to production, infrastructure developers turn to a deployment pipeline to build IT.
Ask a systems, database or network administrator to construct a build-release pipeline, and you might receive a blank stare. Software developers write the application code, which rides on top of the infrastructure built by admins. But sys admins -- soon-to-be infrastructure developers -- don't get out of coding that easily.
Software, unlike hardware, is dynamic. Software is just code that can be changed at will with a few keystrokes. Hardware, on the other hand, is bulky, requires manual intervention -- without fancy robots -- and doesn't scale well. Guess what ops traditionally has been managing over the last few decades? Hardware. VMs have been around for a long time, but that was just the tip of the iceberg. Software is eating the world, as Marc Andreessen, Silicon Valley investor, famously said, and it's coming to operations whether you like it or not. The process by which software is delivered and used by operations is called a deployment pipeline.
Deconstruct the pipeline
Software developer-written code isn't the final product delivered to the user. For example, an executable (EXE) file in Windows is built from code, but the user doesn't see it. When the file is executed, the application follows those code instructions and runs. The EXE file is compiled -- converted from human-readable code into a machine language.
Infrastructure code must be actioned before reaching the user via the deployment pipeline. These actions are a process called a build. A build is just the collection of things that must happen to make code usable. An example build could consist of the infrastructure developer working to compile code, test for bugs, run scripts and make copies of files.
A release is the final stage of a build -- once all actions are complete -- and involves the instructions to deploy the results of the build. A release is when one or more scripts deploy code to a testing environment and publish it in a publically accessible location.
Build IT infrastructure as code
Code is the basis of a deployment pipeline. Modern IT operations deals with code on a daily basis. But not all code is created equal. System administrators do not have to become software developers, but rather infrastructure developers. Infrastructure developers and architects write instructions to build servers, network configurations and more without grunt work.
Operations will write scripts and infrastructure as code to create all of the instructions ahead of time to provision and manage the IT infrastructure and subsequently execute those instructions. For example, an infrastructure developer puts together an extensible markup language file that represents each component installed on a server and a corresponding script that processes it and spins up everything represented within. Tools such as Microsoft PowerShell Desired State Configuration make configuration scripts that contain all of the instructions to provision an entire environment.
Source control essentials
Admins handling code vital to an organization must have a way to not only save this code, but also revert to previous versions. Code must be accessible to multiple people simultaneously. This requires a source control system, such as Git, cloud-based GitHub or Microsoft Visual Studio Team Services. Source control is the first step in the deployment pipeline. It's the gateway that commits code into a large project. When it saves the current file, it creates a change set -- a marker that allows the system in use to revert to that exact version of the code at any time.
Adopt deployment pipelines for operations
Code is code, but infrastructure code is different in some respects. Software developers rely heavily on unit tests, which test the code itself; an infrastructure developer needs unit tests and infrastructure tests.
Because this setup builds infrastructure instead of applications, infrastructure tests are necessary to confirm the code, as written, provisioned or changed what it was supposed to. As an example, to ensure a line of code installs Internet Information Services (IIS) on a server, other code performs tests against that server, such as checking that a Windows feature was enabled, that the expected website was created or that all of the application pools came up successfully. Code quality is always a priority, but when the final product is infrastructure, it tends to have more dependencies and conditions – generally, a messier deployment scenario than applications.
Create an example deployment pipeline
For this example, you'll build a new testing web server for a software developer. This developer needs Windows Server 2016, plenty of disk I/O capacity for his tests to run, various pieces of line-of-business software and IIS installed and configured. The typical deployment pipeline to build IT infrastructure looks like this:
- An infrastructure developer writes code to provision a web server and runs tests to confirm her code is successful, whereupon it is checked into source control.
- The source control system turns the code over to the build system, which runs unit tests against the code. The code must pass the unit tests to advance.
- The build system brings up the necessary dependencies, such as a VM, to test the software.
- Once the VM is active, the build system runs the code against the previous build VM.
- When the tests are complete, the build system runs infrastructure tests to confirm the server was built as intended. If the infrastructure tests pass, the code is confirmed ready, and the VM built for testing is destroyed.
- Once multiple successful builds are performed, a release is scheduled.
- The release collects all code in the project and deploys it to the user-accessible location, such as a self-service portal.
If at any point the code or tests fail, the build system will stop and notify the infrastructure developer.
Deployment pipelines and infrastructure as code are new to many operations admins. Moving software coding into an infrastructure role is a major culture shift, but the ability to script, automate and standardize deployments yields a much more reliable, scalable and manageable infrastructure.
