In this series, we are going to examine the Ops side of the DevOps process that is nicely represented by the 12 Factor App site (12factor.net). Many struggle with understanding the steps needed to embrace the DevOps culture and it is with good reason. There is a lot of change required for people, process, and technology as part of the transformation to the DevOps style.
There is some great information that I use to help view the end-to-end guide on how to effectively build software that will operate in the SaaS (Software-as-a-Service) or a web application environment. This may live inside or outside of your firewall, but the core tenets of the application and infrastructure requirements are ones that can truly make the development and deployment a seamless and frictionless process. Or, as close as one can get at least.
It all has to start with the first fundamental rule which is around the storage of code. While Operations teams tend to think solely about the supply side of infrastructure, it is important to understand how to be able to consume these resources programmatically before we can truly embrace and achieve DevOps methodologies in the organization.
We often hear the phrase Infrastructure-as-Code. This is a great descriptor of what we are working to achieve. By turning our infrastructure and applications entirely into representative code, they are easily replaced rather than having to work through tedious and risky upgrade processes. This spawned the newly popularized term immutable infrastructure:
It all starts with where you keep the code. The reason that having a single codebase is of absolute importance is that the environment must use a single design, and a single deployment methodology. In the past, many organizations have faced the pain of having multiple environments that each has their own codebase, or some oddities that were environment-specific. There can be configuration components within the code (which we will visit later in the series), but the the important thing is to have one repository, and multiple destination environments.
This is important because it ensures that as code is deployed in to testing, QA, pre-production, and production environments, the
Making IaC a part of the application lifecycle management (ALM) process is all done here in the same repository. Build recipes and manifests must be also kept with the code, versioned, and tested thoroughly with automated test to ensure that deployments are identical across all environments. As you saw in our previous Devs are from Venus series about Docker, the inclusion of the infrastructure is already accounted for with a Docker example. This is an important reason why Docker is becoming a powerful tool for development teams as they look to find infrastructure+application possibilities to ensure consistency across deployments.
Automate Testing Included
There will be much more that we discuss down the road about the inclusion of automated tests in the code. Suffice it to say, automated testing is a must because of the build-release-run cycle for software builds that are going to be key to successful ALM for this application and others.
As every feature is added, so too must a test to ensure that during the build process and release process that you can be confident that no regression of features or bugs are introduced. It isn’t that tests stop bugs, but they do make sure that existing features are maintained.
What is the Right Repository?
Whatever works for your team is the answer here. Git is my version control tool of choice, and I use Github for a code repository, but that relies on external services which may not be a good fit for your team. You may want to deploy a Git-compatible repo infrastructure on-premises using a variety of software options. The question will come as to whether you want internal and external code contributors, as well as integration with a testing and review system such as Gerrit.
If open sourcing your software is part of the plan, then you don’t have to look too far to find that Github and SourceForge are the de facto standards among much of the open source community.
With all of this in mind, we will take a practical walk through creating a sample environment and simple application to get you started. Look for that very soon in the next part in our series! For more details about the dev-focussed side of this, I also encourage you to read the 12Factor page on the codebase to match up with what we have started here.
Image sources: Screenshot – Wikipedia definition (https://www.google.ca/search?q=define%3Aimmutable+infrastructure) , 12factor.net (logo) , http://12factor.net/codebase (diagram)