Knowing that there are more implementations of “DevOps” every day, it isn’t hard to imagine they are broadly different when comparing one to another. DevOps is still fairly new as a methodology and there are as many points of view on what an implementation should accomplish as there are organizations practicing it. Is it just an enterprise concern? Should companies deploying service applications (SaaS and other network-based apps) be practicing agile in DevOps? Should every deployed application be managed as though it was meant for a continuous improvement and maintenance system? These are just some of the broad questions being asked as it comes into play.
DevOps was spun out of many developments in the software development and IT operations world around 2009. During that time, agile was fairly well established in the movement away from waterfall development to continuous, iterative development cycles. IT was still primarily waterfall-based, but being hit with waves of change from the Lean, Theory of Constraints, IT service management (ITSM) and operations management movements. The friction between development and operations approaches caused the value from iterative development to be lost in the process of deployment to users. The resolution created parallels between agile and DevOps that are easy to map:
[lgc_column grid=”50″ tablet_grid=”50″ mobile_grid=”100″ last=”false”]
Agile in DevOps
- Agile Values – The core values of agile – the Agile Manifesto
- Agile Principles – Agreed upon strategies that support the Manifesto, usually stated as the Agile Principles.
- Agile Methods – Process implementations such as Scrum, XP, or in-house processes.
- Agile Practices – Tactical techniques used in specific implementations that add value to the process such as standups, backlogs, planning poker and other artifacts of the method implemented.
- Agile Tools – Specific tools or apps that can be used to facilitate the work process such as JIRA, Bugzilla, KanBoard and others.
- DevOps Values – Can be expressed with the Agile Manifesto as well, with the addition of a focus on the overall service or software delivered to the customer/end user. Also echoed in “People over Process over Tools” by Alex Honor.
- DevOps Principles – There are many different lists in play across implementations but most broadly follow Agile Principles with the inclusion of the systems and operations required to deliver software functionality to end users instead of stopping at code check-in.
- DevOps Methods – Many implementations are just extended agile methods such as Scrum with operations, Kanban with operations, etc. As long as the entire value chain is integrated into one agile system (product dev, software dev, QA, operations) it can be said to qualify. There are many new methodologies being tried, but few have risen to a standard level.
- DevOps Practices – Specific techniques such as continuous integration and continuous deployment, toolchains, metrics, monitoring, virtualization, standard environments, etc. All practices used to accelerate change and lower risk in the deployment and operation of applications.
- DevOps Tools – There are so many tools in use today, they tend to over-shadow the actual basic values and principles being employed, but because of the integration and automation needed to implement smooth, incremental deployment of software, they are an important aspect of all implementations. Puppet, chef, TeamCity, OpenStack, AWS and many others fall into this category.
To get above the hype, it is important to understand that DevOps is not just tools – just as agile development is not just a methodical implementation of scrum. If the entire value chain that delivers software to end-users does not buy into the values and principles behind the methodology – benefits will be lost. All the stakeholders in the chain must be part of the agile collaboration that is embodied in the system. In practice, this means that testing automation extends to into deployment staging, and integration testing extends back into early development to avoid loops and blocks that slow down delivery and require rework. The definition of “done” is moved to the right in the development process to the release to end-users and everything else is moved to the left as far as practical, allowing the value of incremental release to flow through.
In some organizations, the system is formalized as an Agile Release Train (ART) and treated as one team with release activities included in sprint planning and DevOps activities in the application backlog. Generally, whether they are formally designated or not, to gain value from DevOps practices, agile practices need to be used across the entire release train. So, coming back to the question – is there agile in DevOps? Yes, there has to be or it doesn’t work successfully.
Nuts and Bolts – The Deployment Pipeline
No matter what term you use to define it – the primary characteristic of a DevOps implementation is the continuous delivery system to the end user – the deployment pipeline. This includes all the people, principles, processes and tools required in a flexible, repeatable and to the extent possible, automated system. The scale of the pipeline will vary depending on the size of the organization and complexity of the software stacks being managed, but the basic principles remain the same.
- Production-equivalent staging environment – The closer the staging environment is to the configuration of the production environment, the better it will be for build testing. Typical DevOps staging environments will include version control, continuous integration, test frameworks, configuration management, etc. in the build system.
- Flat, integrated development and test environments – In line with staging, the actual environments used across the pipeline (down to the developer level) need to match as closely as possible. This means that the entire DevOps team has to participate in propagating configuration changes forward and backward across all environments in the chain. The changes are generally captured in version control and implemented in the scripts and automation throughout the system.
- Deployment to staging every iteration with deployment to production frequently – It is certainly necessary to deploy to staging every iteration – it is what gives development and operations the confidence that code can be deployed to production safely. But, while it is beneficial to release to production as often as possible, it may make sense to delay some iterations to allow full feature sets to be delivered to users, allow evaluations of regulatory and security issues, and to handle potential impacts of changes to customers and external market forces.
- End-to-end version control – Using version control to manage all the artifacts, metadata, supporting configuration and test data may seem like overkill at the beginning, but when a change is made, if there is not a central point to manage the data, pieces will certainly fall out at the wrong time.
- Automated builds for environments – With virtualization, tools and scripts can be brought together to automate the building of environments to ensure they can be quickly and consistently deployed. It also allows a wider range of team members to deploy standard environments without waiting for specific, skilled individuals to be available.
- Automated deployment to production – It may seem obvious, but many organizations have failed at this end of the pipeline because there are so many stakeholders in the organization that it becomes impractical to get them on the bandwagon before a DevOps implementation is started from the development end. It is, of course, a great waste of time and effort, if the final mile to the customer, end-user is not automated in the same way the development side is done. It may be practical to test a DevOps deployment pipeline up to production first, but it needs to proceed through to production as quickly as possible so the initiative doesn’t lose momentum.
None of this is light work and it requires cooperation and collaboration across the entire organization to both implement and maintain over the long haul. And while we’re at it – what if you have an outsourced development team in the mix?
Outsourced Teams in the Pipeline
So, let’s think about what we’ve said:
- Everyone needs to be on the same page, committed and involved in the agile, end-to-end process of continuous delivery to end users.
- Staging, working environments, testing automation – the entire deployment pipeline needs to be as flat and consistent as possible. Every step away from the production environment and deployment process will introduce risk and unknowns that will eventually create problems.
- Because the desired outcome is assumed to be continuous delivery to end-users, not a discrete software development project, it is assumed that a dedicated development team is required.
What does this tell us?
- Either the outsourcing vendor will need to replicate the environment on their infrastructure locally or they will need to work remotely in the host DevOps environment. Either is possible, but for agile teams, it is more likely they will work remotely across the Internet. This means the remote team needs the infrastructure and security to meet the requirements and work efficiently.
- Real-time collaboration and communication are critical. With more people, pieces and processes in the pipeline, more collaboration is necessary to ensure things continue to run as planned in all segments. A 12-hour delay or a circular cycle of questions over several days is simply not a workable outcome for continuous delivery. Nearshore or geographically close vendors are going to be best positioned to deal with the requirements in these cases. Language, cultural issues, etc. should not be allowed to be barriers in these situations.
- Vendors need to be fully engaged in getting their teams up to production speed and involved in working directly as part of the team. This will certainly require some face-to-face meetings and team building work, just as it does for any new agile team.
Can it work?
Yes. We have participated in projects with DevOps implementations and been strong members of the team throughout the lifecycle of the application. Yes, there are moving parts involved, but this is true regardless of where the team is located and how it is integrated into the organization.
Is it all worth it?
In many cases, certainly. A lot depends on understanding the value of the continuous release of software to your organization. It is a shift if you are not currently releasing continuously, but it makes a lot of sense if you want to be able to react to changing circumstances quickly and realize value from feedback from end users with less delay. It also makes sense if you want to lower your risk from large, unscripted changes (that change from version 1.0 to 2.0 that had to be delayed and finally rolled back) and costly rework.
Scio is a provider of nearshore software development services to our clients in North America. We have extensive experience in DevOps environments with dedicated teams working remotely. If you have a question or a requirement you would like to discuss, contact us for more information.