Since its inception, devops has been debated in IT circles. Some have considered it a marketing fad; others have believed it will revolutionize IT operations. Year after year, analysts predict rapid growth, and while the devops movement has grown at a steady pace, it hasn’t yet caught fire among more mainstream organizations. Here, the blame largely falls on those businesses that have failed to understand devops and how it can provide significant value to their operations.
Devops has evolved from a methodology to bring developers and operations teams together into a strategy for transforming an entire business into a single operational entity. By facilitating greater communication, collaboration and integration across the organization, devops significantly improves the agility of IT service delivery and simplifies IT management while optimizing costs.
What is devops?
Devops is an IT philosophy and practice that brings development, operations and testing personnel together in cross-functional teams, each of which is responsible for the entire lifecycle of a software product or service. By bringing together collaborative teams across the organization, devops creates a stable operating environment for bringing code to market faster, reducing human errors and bugs, enhancing version control and optimizing costs — all while improving resource management.
The devops journey
Your devops journey begins by exploring your current business procedures and delivery pipelines, and identifying clear objectives you want your devops strategy to achieve. You’ll need to decide whether you want to tackle greenfield or brownfield deployment. Greenfield deployments are built from scratch, making them easier to implement but prone to downtime as services are provisioned via the new deployment methodology. Brownfield deployments result in less downtime but are often harder to implement due to the need to rely on parallel deployment methodologies. Think of brownfield deployment as trying to fix a car while it’s going 55mph down the road.
Whatever you choose, it’s best to run a pilot project first. For instance, if your objective is to achieve a faster time to market, you can move a product that has strict deadlines to the iterative devops model and check out the impact.
Once you have a project in mind, the following six steps are essential to devops success.
1. Prepare for a cultural shift
Devops integrates people, processes and tools together to transform an organization into a single entity. As such, cultural shift is the backbone of devops, and changing your company’s culture will be one of the most difficult challenges you’ll face. Simply introducing new policies and procedures, while perhaps initially successful, will fail in the long term unless the underlying organizational culture is also changed.
Successful devops is a companywide movement that begins with top-level management and runs down through entry-level staff. You will need to disassociate name from function and ensure that developers and operations personnel are informed of the value each brings to the organization before bringing them together into cross-functional teams.
To facilitate your cultural shift, incentives should shift as well. The most effective incentive model is to reward cross-functional teams for delivering a better customer experience while making any failures as inexpensive for the organization as possible. Some organizations ask developers to work on-call so they can understand operations challenges. Some expedite the cultural shift by identifying rock-star developers and operations staff to help motivate other team members. Others help groom a likeable grassroots leader for each team to help make the transition to devops much smoother.
2. Create a continuous integration, continuous delivery platform
Once the whole organization is on board, your focus should turn to the devops team itself. Here, the main issue is to provide developers with accurate, up-to-date information about the production environment so they can plan deployment appropriately. This will ensure that developers can focus on a coordinated “build and run” approach in which the developer who builds a product or service “owns” that product or service through to production. This “ownership” can extend for a set period of time, to ensure major bugs are addressed before handing off, or for the lifetime of the product or service. Both approaches work, but the key is that operations, while perhaps the first point of contact, is no longer left holding the bag when it comes to solving issues in the field.
The devops team will touch all points of the service lifecycle, from requirements through to planning, deployment and maintenance. This team, with its deep knowledge of the platform and infrastructure, will also troubleshoot and debug problems — a function that traditionally falls on ops. Here, the key is to create an automated deployment pipeline, wherein the deployment of a fully automated script on any environment happens within minutes. The deployment pipeline should integrate continuous integration, continuous development, continuous testing and continuous deployment into a single entity.
Here’s how it works:
- A code change committed to a source control system triggers a process on a build server.
- This process compiles the code, bringing together the artifacts necessary for deployment to customers into deployable packages.
- Automated tests are then performed on these packages to ensure code quality is retained and the code performs as expected.
- If the commit stage is successful, the application is deployed to a test environment where it can be inspected by a quality assurance team, for example.
- Finally, once the application has been approved, that same release can be pushed straight to production.
3. Create a continuous testing environment
The quicker you receive feedback on changes, the better your software quality will be. In the traditional waterfall process, the complete code moves from development to the testing area and is then pushed to production if it successfully passes the test. If not, the code is sent back to development for editing. This takes more time and is less reliable.
With devops, testing becomes an integral part of development, and QA personnel are part of the cross-functional devops team. Testing, whether manual or automated, is performed continually throughout the delivery pipeline. Every change is treated like a potential release candidate, and the goal is to keep the time between check-in and release as short as possible. As a safety measure, create a skeleton delivery with a single unit test and a single acceptance test that is integrated with your automated deployment script. As you move forward, you can increase the number of tests and spread them out across the delivery pipeline.
Continuous testing best practices include:
- Automate testing procedures and phases to the greatest extent possible (manual testing is necessary in certain areas, such as usability testing and exploratory testing).
- Separate test suites for easy and quick testing procedures (e.g., developers can quickly perform unit tests before commits, while integration tests can be run on build servers).
- Log extensively.
- Test early and frequently.
- Make sure to add sufficient QA practices.
4. Establish a continuous deployment system
Continuous deployment extends continuous delivery. Each build that successfully passes a full test cycle is automatically deployed. It eliminates the need for human intervention to decide what to deploy and when to deploy. With continuous deployment, organizations can quickly deliver new features and updates while proactively making changes to the product.
Because there is no manual verification before code is deployed, continuous deployment can seem a bit scary. You don’t need to worry about losing control over the code in production when you have a well-designed delivery pipeline. Plus, devops can give you more granular control over the functionality of a given service by making certain builds available only for selected users or by automating the release of features at a specified time.
Your developers should ensure the code they write is well-designed, and QA should create test suites that are always up to date. When your delivery pipeline is properly designed, the system automatically decides what and when to commit to the repository, what and when to release to production, and so on.
Continuous deployment should be augmented by continuous monitoring and feedback. With early feedback, developers know what features are useful to end-users. This helps them focus on the features that matter most, saving time and effort.
5. Make use of blue/green deployment
To reduce downtime and mitigate risks, organizations can consider what’s known as blue/green deployment. In this method, when a change is made and a new deployment (blue) is triggered, it is deployed in parallel to the old one (green). Both deployments run side by side, and initially, a small amount of traffic is routed to the blue deployment. If it is successful, the rest of the traffic is slowly routed to the blue deployment and the green deployment is gradually removed. If it fails, traffic goes back to green and the blue is removed. This enables you to switch between deployment environments without any downtime or system crashes. This is how sites such as Facebook or Twitter introduce new features, as they can’t halt their services at any time.
6. Continuously monitor performance
In an automated environment, performance monitoring is key, and there are several tools to help. Before you choose your tools, you need to identify the key metrics you want to monitor. Given that you will have hundreds of services and procedures running inside your system, you won’t be able to monitor everything. Instead, focus on the following five important categories:
- Development cycles: To get a sense of how your automated deployment pipeline is performing, monitor how frequently the code is being changed, how many objective features are being incorporated, how many bugs are being identified and fixed, and so on.
- Deployments: When an automated deployment fails, you’ll want a tool that alerts the assigned team. Most continuous integration servers come with notification features that alert assigned personnel automatically via chat servers in case of a failed deployment or build.
- Vulnerabilities: As code moves into production, vulnerabilities should be handled automatically. Be it known vulnerabilities (e.g. those listed in the National Vulnerability Database) or unknown vulnerabilities that are a result of insecure practices, you should have a system to identify and mitigate them.
- Server health: Server monitoring is essential with almost every type of infrastructure, not just in devops. The performance and service-level agreements (SLAs) of the system are dependent on the health of the server. There are several tools to perform this task. Similarly, you should have infrastructure monitoring in place.
- Application performance: To identify key issues such as performance and regression of applications, monitor application activities and make decisions proactively. Multiple tools can serve this purpose, including AppDynamics and New Relic. These application performance monitoring (APM) tools give you insights into application usage and performance.
You’ll also want to analyze application logs. Log monitoring tools collect large amounts of data from various sources and centralize them in a database. User activity monitoring is also key. By gaining insights into resource usage and user behavior patterns, you can scale up the infrastructure while introducing new features or improving the performance.
You’ll also need to address regulatory compliance. In addition to designing and enforcing strong security polices, you should have a system to monitor for failed audits or security misconfigurations. Configuration management tools such as Puppet continuously monitor your infrastructure for compliance and automatically remediate your systems back to the desired state.
While devops success depends largely on the underlying cultural shift, tools are still important. Here is a brief list of some of the tools typically used in a devops environment:
- Source code repository: Git, CloudForce, TFS, Subversion
- Build server: SonarQube, Jenkins, Artifactory
- Configuration management: Puppet, Ansible, Salt, Chef
- Test automation: Selenium, Water
- Virtual infrastructure: Amazon Web Services, Microsoft Azure, VMware vCloud
Moving from traditional software development to devops is challenging, as it involves a significant change across the organization. The key is to assign the right people for the right processes while equipping them with the right tools. As long as you follow best practices in creating a delivery pipeline with continuous integration, continuous testing, continuous delivery and continuous deployment, a switch to devops should reap significant rewards for your organization.
More on DevOps: