sexta-feira, 6 de julho de 2012

Continuous Delivery: why you should be doing this?

If you are not doing, or not going in the direction of doing, Continuous Delivery (CD) I would say you are going down to the wrong path. I know, I have strong opinions (see my post Are you agile? really?). But this is the only way I could see software development in large scale* work. Not saying it is an easy path (I would mainly blame the culture of avoiding/blocking changes), just saying that you should start thinking on its benefits and also you should start trying out those techniques.

It is important to mention that this post will not discuss continuous delivery strategies, techniques or patterns. For that you should read the Jezz Humble’s book and search for it on web. I’m sure you will find hundreds of wonderful materials on this subject.

So, why you should be doing continuous delivery?

Lots of people think Continuous Delivery is an extension of Continuous Integration where the focus is on "solving the last mile”. Although this is kinda of true, it necessary to look at the whole idea behind Continuous Delivery to figure out that it is much more than “the last mile”. Let’s discuss some key points:

Manage IT risks in a simple and efficient way

Automate testing is one of the key strategies in continuous delivery world. A well design pipeline includes, at least, unit testing, service testing, functional or acceptance testing, smoke testing and provisioning testing. So, going down this pipeline means you are testing every piece of your software, including infrastructure. Knowing this will happens dozens of times per day you are then reducing the risk of going live.

Respond as fast as possible whenever an issue happens

Continuous Delivery does not eliminate all bugs/issues from going live -- although I’m secure to say it reduces most of them. So, when these unpleasant things happens, CD plays in your side. Let’s see an example:

The above picture shows the time spent to figure out a problem an then the respective time spent to fix that in an traditional delivery process.
On the other hand, it is possible note in the above picture that both time to discovery and to fix a problem in production is much smaller in CD than it is in traditional processes. This happens because:

  1. Once you goes frequently to production, you have much smaller batches, then you have much smaller problems. Simple like that.
  2. Even if you have an issue that requires to rollback the whole installation, it is much easier to do this task in CD since you have all the software and provisioning scripts marked into SCM.
  3. As you must already know, going back must be the last option. In CD world we used to say “go forward”. That means, fix the problem and reinstall. Your process was planned for that.

Delivery of reliable products

As discussed previously, continuous delivery depends on automated testing. So, it is all about doing regression tests many times per day. That means, whenever a developer makes a change in a module A that breaks another module B, in which he is not responsible for, it will be known as soon as the pipeline starts. Therefore, you get confidence whenever you deliver a new version of the product.


Another interesting point is that this amount of testing actually encourages refactoring. And, periodically doing refactoring we ensure that our software will ever be up to date. Without such strategy, delivering a new version of your software means you already have a legacy.

Reduce the cost of the product

As any software engineering knows, the cost of fixing a bug/issue grows in price according time passes (see the picture below). Continuous Delivery is all about discovering this kind of stuff as early as possible in the pipeline, reducing then the product’s cost as a whole.

Builted-in software quality

It is not possible to do continuous delivery without doing continuous integration. Therefore, all the good stuff of continuous integration is earn for free. ;-)


One of the main strategy behind continuous delivery is the “on click” slogan. That meas that with just one click or two (or a command or two) you are able to delivery your software -- including all the infrastructure it depends to run on top of. To make this possible, you must automate almost every step of your delivery process. Doing that, you have a fast, reliable and repeatable delivering process.

Spread delivery knowledge

In most of companies I’ve being working for, the delivery knowledge is focused in a delivery team. Some times, this team was composed by only one person. Whenever this person decide to look for new opportunities and you have an urgent deliver to do, certainly you got into trouble. Why? 
Just because:
  1. You don’t know detailed steps to delivery your software
  2. Documentation is, usually, not up to date
  3. When you go into the delivery process you start to see the hack people do for delivering

With Continuous delivery you just press a button. Then, after delivering, you have enough time to look into the process for understanding and, maybe, improving.

Infrastructure fully documented

Every build and delivery step is “configured” in a programmatical way. So, whenever you would like to know how infrastructure work in any environment (i.e. development, staging, production, etc), just checkout the the code from SCM and take some time to understand the logic.

Documentation will never be out of date

Even better than have fully documented environments, is that this documentation will never be out of date. Whenever it gets out off date your continuous delivery process will advise you by failing some stuff in the pipeline... Amazing, don’t you think?!?!

This is one of the key benefits from Continuous Delivery that is not so commented in papers on this area.

Learning from real data usage

"When you think about it, the concept of continuous delivery isn't really new. Creating a hypothesis, developing the hypothesis, testing it, and controlling for other variables by isolating the one that changes—that is, the scientific method—isn't exactly controversial. While Agile certainly has made strides, putting a greater emphasis on making sure that testability is a first-order concern in software delivery work, continuous delivery closes the loop" [source]

Focus on customer necessity

Most of the time customers do not know what are they needs. In other times they do not have enough data for solid decisions. Continuous Delivery and its scientific method help us to focus on actual customers need (i.e. ROI) and not in what they want.

Fast feedback, visibility and control

The build pipeline used in Continuous Delivery is all about fast feedback, visibility and control. Where anyone is able to see the current status of the project just looking at a dashboard (usually shown in a large LCD). 


Dashboards play a key job in CD world. Nobody should be asking for things like: Which version is being tested? Which version is in production? Which build has failed? Why it has failed? Where can I find the log? etc.. etc.. A good Dashboad should respond this and many other question for just looking at it.

Concluding remaks

All these good stuff guarantee that the product will arrive in production as fast, as mature, as stable and as reliable as possible. Besides this, doing continuous delivery is a fun task in which every time you finish a process automation you will find another part to automate or improve. As Jezz Humble once told: "we will never be done". :-)

So, my advise is: you are already late! Start using continuous delivery.


* In this context large scale means more than few developers. :-)

sábado, 19 de maio de 2012

Are you agile? really?

Lately I’ve heard a lot of software companies saying they are agile. However, when you start a conversation with the representative of these companies you can easily notice that Scrum is the only word they know about being agile.

Nowadays be agile means be "modern". Developers want to work in agile projects. Customers are looking for agile companies/consultants. Even Gartner predicted in 2010 that "agile development methods would be utilized in 80% of all software development projects". So.. what is the point?

Well.. the point is:
Be agile  !=  do Scrum

Actually, be agile is much much more than do Scrum variants. Be agile requires the team to feel and act as agile. It must be running into the veins of the developer. But, unfortunately, what we can see is that the word agile is being used as marketing purpose by many companies.

While discussing about that with a friend I’ve decided to write down my thoughts about this subject. So, in my point of view, you ARE NOT agile if:
  • if you don’t focuses in built-in quality
    • There is a principle on the Agile Manifesto that says “continuous attention to technical excellence and good design enhances agility”
    • Agile teams must feel pleasure delivering high quality software. The era which said that software process ensures software quality have finished a long time ago. You must focus on quality from inside-out. That is, the code must be high quality, so that the functional may fit the user expectations.
    • With a poor code you have: more bugs, poor performance, poor extensible strategy, unreadable code, etc.. Consequently, you have a customer less happy.
  • if you are not able to make your customer to work in your side
    • don’t need further comments..
  • if you do not pay technical debits
    • I know “agile” projects that have failed because, in only two years, the software started to deteriorate. But why? the answer is simple: because developers didn’t know what technical debt is..
  • If you do not automate tests (in all levels)
  • If there isn’t regression tests
  • If you do not refactor your code
  • If you do not enhance your design/architecture
  • If you do not use continuous integration
  • Nowadays I would say, If you do not use continuous delivery
  • If you do not monitor your software when it goes live
  • If you do not learn from your live software
  • If you can point a person or a developer as the responsible for a delivery failure
  • If you do not trust in your team
  • If your team is separated by sites (i.e. DBAs, testers, developers, etc)
  • if you do have more trainees and junior developers than senior ones
    • The problem is that most companies which say they are agile have more trainees than senior developer. In these companies the software quality tends to be poor. I would like to say that there is nothing wrong with trainees and junior developers. The only point here is that they don’t have enough maturity to make decisions or to enhance the software design.
    • As any other software methodology, trainees must added into an agile team in a planned manner.
  • If you try to institutionalise a process that have worked for another team
  • If you do not use working software as the primary measure of progress
  • If you do not continually improve your process
  • If your process do not welcome changes
  • If you have closed scope contracts
    • Be agile in closed scope projects is extremely hard. This is possible if you have a very tiny software, but with large ones practice have shown us that it is not possible  because you will reject changes or make changes difficult to happens. What goes against one of the main principles of the Agile Manifesto.
  • if you have large iterations
    • One month seems to long for a delivery. One or two weeks is a nice shot
  • if you can not break your requisites to fit into a sprint
  • If you do not use MVP (Minimum Viable Product).
  • If you say ‘done’, when the functionality is not shippable
  • ...

It is important to say that there is nothing wrong with a company trying to use Scrum, Kanban, XP or whatever. What I’m saying it is wrong is that there are many companies using the word agile as a marketing purpose only. They have no process, no adequate team and because they’ve started to do stand up meeting and put some notes on a blackboard they sell themselves  as agile.

Just because you’ve started to use Scrum and Kanban does not means you are Agile. That means you've done the baby steps to the “right” direction. Be agile is more difficult than most of people think.. That is why there is only few companies in the entire world that REALLY are agile.

Please, leave your comments.. I will appreciate them..