(For more resources related to this topic, see here.)
What is continuous delivery and DevOps?
Let's start by looking at each separately:
Continuous delivery, more commonly referred to CD, is an agile way of working whereby quality products—normally software assets—can be developed, built, tested, and shipped in quick succession.
CD is a refinement on traditional agile techniques such as scrum and lean. The main refinements being the ability to decrease the time between deliveries and the ability to do this many many times—continuously in fact. Agile delivery techniques encourage you to time-box the activities/steps needed to deliver software: definition, analysis, development, testing, and sign-off but this doesn't necessarily mean that you deliver as frequently as you would like. Most agile techniques encourage you to have "potentially shippable code" at the end of your iteration/sprint. CD encourages you to ship the finished code, as frequently as possible.
To achieve this ability one must look at the process of writing software in a slightly different way. Instead of focusing on delivery of a feature or a project in one go, you need to look at how you can deliver it in smaller, incremental chunks. This can be easier said than done.
DevOps is another way of working whereby developers and system operators work in harmony with little or no organizational barriers between them towards a common goal. This may not sound too radical however when you consider how mainstream organizations function—especially those within government, corporate, or financial sectors—and take into account the many barriers that are in place between the development and the operational teams, this can be quite a radical shift.
A simple way to imagine this is to consider how a small start-up software house operates. They have a limited amount of resource and a minimum level of bureaucracy. Developing, shipping, and supporting software is normally seamless—sometimes being done be the same people. Now look at a corporate business with R&D and operations teams. These two parts of the organization are normally separated by rules, regulations, and red tape—in some cases they will also be separated by other part of the organization (QA teams, transition teams, and so on).
DevOps encourages one to break through these barriers and create an environment whereby those creating the software and those supporting the software work together in close synergy and the lines between them become blurred. DevOps is more to do with hearts and minds than anything else so can be quite tough to implement when long established bad habits are in place.
Do I have to use both?
You don't necessarily need to have implemented both CD and DevOps to speed up the delivery of quality software but it is true to say that both complement each other very well. If you want to continuously deliver quality software you need to have a pretty slick and streamlined process for getting the software into the production environment. This will need very close working relationships between the development teams and the operations teams. The more they work as one unit, the more seamless the process.
CD will give you the tools and best of breed practices to deliver quality software quickly. DevOps will help you establish the behaviors, culture, and ways of working to fully utilize CD.
If you have the opportunity to implement both, it would be foolish not to at least try.
Can CD and DevOps bring quantifiable business benefit?
As with any business the idea is that you make more money than you spend. The quicker you can ship and sell your service/software/widget, the quicker you generate income.
If you use this same model and apply it to a typical software project you may well notice that you are investing a vast amount of effort and cash simply getting your software complete and ready to ship—this is all cost. That's not the only thing that costs, releasing the software into the production environment are not free either. It can sometimes be more costly—especially if you need large QA teams, and release teams, and change management teams, and project coordination teams, and change control boards staffed by senior managers, and bug fixing teams and ... I think you got the idea.
In simple terms being able to develop, test, and ship small changes frequently (say many times per day or week) will drastically reduce the cost of delivery and allow the business to start earning money sooner. Implementing CD and/or DevOps will help you in realizing this goal.
Other business benefits include; reduction in risk of release failures, reduction in delivering redundant changes (those that are no longer needed but released anyway), increased productivity (people spend less time releasing product and more time creating products), increases competitiveness, and so on.
How does it fit with other product delivery methodologies?
CD and DevOps should be seen as a set of tools that can be utilized to best fit your business needs. This is nothing new, any mature agile methodology should be used in this way. As such you should be able to "bolt" elements of CD and DevOps into your existing process.
For example, if you currently use scrum as your product delivery methodology and have implemented CD, you could tweak your definition of done (DoD) to be "it is live" and incorporate checks against automated testing, continuous integration, and automated deployment within your acceptance criteria for each story. This therefore encourages the scrum team to work in such a way as to want to deliver their product to the live platform rather than have it sat potentially shippable waiting for someone to pick it up and release it—eventually.
There may be some complexity when it comes to more traditional waterfall product delivery methodologies such as PRINCE2 or similar however there is always room for improvement—for example, the requirements gathering stage could include developers and operational team members to flesh out and understand any issues around releasing and supporting the solution when it goes live. It may not seem much but these sort of behaviors encourage closer working and collaboration.
All in all CD and DevOps should be seen as complementary to your ways of working rather than a direct replacement—at least to begin with.
Is it too radical for most businesses?
For some organizations being able to fully implement the CD and DevOps utopia may be very complex and complicated, especially where rules, regulations, and corporate governance are strongly embedded. That isn't to say that it can't be done. Even the most cumbersome and sloth like institutions can and do benefit from utilizing CD and DevOps—the UK government for example.
It does need more time and effort to prove the value of implementing all/some elements of CD and DevOps and those that are proposing such a shift really need to do their homework as there may well be high degrees of resistance to overcome. However, as more and more corporate, government organizations, and other large business embrace CD and DevOps, the body of proof to convince the doubters becomes easier to find.
Look at your business and examine the pain points in the process for delivering your goods/services/software. If you can find a specific problem (or problems) which can be solved by implementing CD or DevOps then you will have a much clearer and more convincing business case.
Where do I start?
As with any change, you should start small and build up—incrementally. If you see an opportunity, say a small project or some organizational change within your IT dept, you should look into introducing elements of CD and DevOps. For some this may be in the form of kicking off a project to examine/build tooling to allow for automated testing, continuous integration, or automated deployments. For some it may be to break down some of the barriers between development and operational teams during the development of a specific project/product.
You may be able to introduce CD and/or DevOps in one big bang but just consider how things go when you try and do that with a large software release—you don't want CD and DevOps to fail so maybe big bang is not the best way.
All in all it depends on your needs, the maturity of your organization, and what problems you need CD and DevOps to solve.
If you are convinced CD and DevOps will bring value and solve specific problems then the most important thing to do is start looking at ways to convince others.
Do I just need to implement some tooling to get the benefits?
This is a misconception which is normally held by those management types who have lost their connection to reality. They may have read something about CD and DevOps in some IT management periodical and decided that you just need to implement Jenkins and some automated tests.
CD and DevOps do utilize tools but only where they bring value or solve a specific problem. Tooling alone will not remove ingrained business issues. Being able to build and test software quickly is good but without open, honest, and collaborative ways of working to ensure the code can be shipped into production just as quickly you will end up with another problem—a backlog of software which needs to be released. Sometimes tweaking an existing process through face to face discussion is all the tooling that is needed—for example changes to the change process to allow for manual release of software as soon as it's ready.
Where can I find more information?
There are many forms of information available in relation to CD and DevOps one of which is a small book entitled "Continuous Delivery and DevOps: A Quickstart guide" which is written by your truly and available here (http://www.packtpub.com/devops-quickstart-guide/book )
In this article we saw some of the most frequently asked questions on Continuous Delivery and DevOps.
Resources for Article :
- Negotiation Strategy for Effective Implementation of COTS Software [Article]
- An Overview of Microsoft Sure Step [Article]
- ER Diagrams, Domain Model, and N-Layer Architecture with ASP.NET 3.5 (part1) [Article]