Continuous Deployment - Why and How

From CitconWiki
Revision as of 21:10, 2 March 2014 by Paulflewelling (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Are you doing Continuous Deployment? How are you doing it?

Define continuous: automated deployment process through all your envs through to production deployment.

3/4 doing continuous deployment

What's the motivation?

1st Example (from group) 1 of our projects configured to deploy continuously. Allows us to iterate faster, speed up delivery, be more Agile.

Potential benefits for us to deliver overall better quality of product

2nd Example (from group) Only to development environment.

As soon as it's check into master it's deployed.

(This is Continuous Integration)

Any reason why you don't deploy to production? The tester has to give the ok before deploy to production.

3rd Example Increase the value of what we're delivering.

Envs were a bit of a mess before we started continuous deployment.

Made our environment management much better.


What's preventing other people?

  • Database migrations
  • Client requiring notifications of outages
  • Don't have tests
  • Managing the media and making announcements

Feature flags can be used to managed the latter, for example Java Togglz http://www.togglz.org

Other people have managed using feature flags. A/B testing very similar to feature flags.

Use UI toggles to manage if features are on or off.

If we don't manage using feature flags, then we have features outside of the main branch that have to be maintained.

Virtualisation services are one way of managing the complexity you've got with turning on/off features in the test envs when you've to manage connections to things like SWIFT (Society for Worldwide Interbank Financial Telecommunication) http://www.swift.com/index.page?lang=en

If you need to change code in production to switch on a feature, does that mean you have to raise a change request? (takes 5 days)

Depends if large organisation and need to have change request. Some orgs just need to know what happened, i.e. they have a record.

Don't need a change request for a feature toggle.

Feature toggles are used in Production so that different groups can test different features.

Another comment: Testers are the people that hate feature toggles the most. Which combination of feature toggles was it that cause the particular bug?

Also the little things that catch you with features toggles, i.e. I told you months ago to turn that toggle on.


Challenges with Continuous Deployment

  • A lot of investment at the beginning
  • Haven't even started down the road of functional testing
  • It's only going to be good as the testing that we do
  • How to manage data migrations in production, have to invest some effort into how we do that, i.e. multiple steps.
  • Who manages the continuous delivery? Developers? Testers? DevOps?

We picked some of the biggest monolithic systems, if I had a choice I would have selected one of our web apps. Instead we chose one of our core banking systems with mainframe, OracleDB, etc, etc. Essentially we selected the system with the greatest strategic importance and the one where we would get our arses kicked by our competitors.

Of the 4 things that you've done are you trying to make it a similar process for the next project that you change?

Some of the code we're dealing with is very old and so are the people that manage it. People change is the biggest challenge.

Basically we're making a conveyor belt so that each project gets shipped in the same way. Unfortunately for some people it is still down to the people who are on the project.

Manage multiple different projects, java, python, PHP in the same way.

How do you get the infrastructure guys to care about this? Well I'm the head of the infrastructure team, so I care about it. The see was planted long ago, moved to Puppet for CM 3 years ago. It's been a long steady process.

Another team using Chef now deploy to Amazon. Takes an hour to configure.

Some team used a bottom up approach, do it in their spare time, etc. IBM used a top down approach.

Others have a R&D time allocated each week.

Management buy in is important to success, otherwise things will get in the way.