The fact is, there’s no single DevOps solution that caters to every organization’s unique needs. If you adopt specific technologies simply because others have done so, it could end up doing more harm than good.
As an essential first step, take time to assess the current state of your delivery pipeline. This will enable you to identify any inefficient processes or areas that can benefit from the adoption of DevOps tools. If you have extended testing times or slow provisioning of new hardware, it means you may have bottlenecks within your system, hurting productivity and increasing feature cycle time.
Bottlenecks within software delivery can appear in many different forms, including:
Who better to ask about bottlenecks than the team that interacts with the software delivery processes on a daily basis? They’ll be able to provide valuable insight.
As the concept of DevOps has grown from buzzword to a necessity in the last few years, the number of tools available to automate processes within the area of software delivery has grown exponentially. These tools can be divided into the five categories below. Organizations that have successfully integrated DevOps principles within their software delivery pipeline automate tasks using tools from each of these major tool categories.
A common myth is that version control is designed to hold source code only. We would like to dispel this myth. The source control should store everything that encompasses a releasable version of your software. In short: application code, infrastructure code, configurations, build mechanisms, and databases should all be maintained using a consistent version control strategy.
The initial time investment required to script all aspects of your software will far outweigh the long-term benefit of being able to view your entire system as a single, releasable unit. If you're doing it right, any authorized team member should be able to re-create any version of the software system at any point in time.
You likely already have a selected version control system in place. However, if you have the opportunity to start from scratch, consider tools like Git/GitHub, Subversion, BitBucket, and Microsoft Team Foundation Server. However, these are not the only version control tools that work well within a delivery pipeline implementing DevOps principles. We have yet to find version control software that doesn’t allow us to integrate well with other technologies. The VC tools mentioned above were highlighted because they’ve been found to be flexible and reliable by a number of organizations, including Slalom.
Some things to consider as you decide on a VC tool are:
PuppetLabs aptly define configuration management (CM) as “the process of standardizing resource configurations and enforcing their state across IT infrastructure in an automated yet agile manner.” Expanding on this definition, you write code that describes desired configuration states, and your chosen CM tool does the heavy lifting to ensure that this configuration is applied to desired targets in a consistent manner. Whether you’re provisioning infrastructure, deploying your application, enforcing server configurations, or updating security policies, configuration management tools automate tasks which were previously performed using slow, manual steps.
Only a few years ago, these tasks would take days or even weeks to complete, with a high possibility of configuration error given the number of manual steps. As more and more organizations shift toward using the scalability of cloud-hosted infrastructure, configuration management tools’ ability to seamlessly apply desired configuration states to hundreds or thousands of nodes at once is extremely beneficial.
There are many open source configuration management tools available. Some popular ones are Chef, Puppet, Ansible, SaltStack, and CFEngine. When choosing a specific CM tool to adopt, consider:
Each of the aforementioned CM tools have advantages and disadvantages, so we recommend taking the time to do your research. Consider some of the questions we’ve raised along with the needs and requirements of your organization before choosing one to use.
Build system software could arguably be the heart of your software delivery pipeline. From compiling code to orchestrating various levels of testing suites, your build system will have a hand in some very important tasks.
Cooperating directly with your chosen version control software, the build system can be configured to validate the integrity of code checked-in by developers and report any build errors and unit test failures. By doing this, the build system acts as a virtual safety net. If build errors are reported or testing suites fail, the proposed changes never make it to the deployment package. The value of this is immense, allowing organizations to have an additional degree of confidence when deploying code to production servers ten or even hundreds of times per day.
The decision on which build tool to integrate within your solution will be based on a number of factors:
With a build system in place, it’s possible to further streamline this process using an artifact repository tool. When we develop an application, we commonly use supporting development libraries from a variety of different sources. These libraries often get stored in the darkest depths of your source control system and become difficult to manage as projects scale in size.
This issue often materializes when multiple teams require access to different versions of a library with an ambiguous owner. Thankfully, situations like this can be avoided through the use of an artifact repository tool, which provides a central repository for commonly employed dependencies. This greatly simplifies the distribution of artifacts among various project teams and has the added benefit of versioning these files.
Along with version control and build system software, deployment tools make up an important part of a software delivery pipeline, because they automate the deployment of code to specific server instances. A number of the build system tools listed in the previous section (Jenkins, TravisCI, etc.) also conveniently offer a deployment component. Using a combined build system/deployment tool will allow you to consolidate some of the delivery pipeline processes, but may lack the flexibility and scripting capabilities of dedicated deployment tools like Capistrano or Octopus Deploy.
When choosing a tool for application deployment, consider:
Organizations that fully integrate DevOps principles within its software delivery process place an immense amount of importance on monitoring. In a previous blog post, we shared how we were able to achieve a 95 percent increase in velocity by implementing DevOps principles with a client. A big piece of that came from monitoring and alerts setup for the solution—like notifying the team when performance was falling on a critical data job for the application. By doing this, the team had a much better understanding of where to start addressing problems, vs. finding out via a user and starting at square one.
When examining available monitoring options to choose from, consider: