Continuous deployment

Some time ago I read about continuous deployment process concept on the Eric Ries blog.

Software deployment is the process of making the next version of your product available to everybody.  For example, if you own a website, and you or your development team has made some bug fixes, implemented some features the moment you upload those changes you are doing a deployment.

I think continuous deployment is the next logical step after implementing a continuous build process. A continuous build generates some artifacts/installers/whatever you will use to update your server, and make those latest changes available to everyone.

This process should be taken carefully, because we should make sure everything is going to be fine on the server. We don’t want to update the server and leave it unstable, nor we want to update it and upload new bugs. It is really important to make sure not only our build is passing all our tests (we have tests to validate our builds, right?), but we should also need some tests to make sure the upgrade process succeeds.

Without going any further, after thinking on this for several weeks, I see several advantages from deploying continuously.  The top advantages I can think of are:

  • your users will enjoy sooner your latest improvements and features
  • you will get feedback from your users right after implementing the new features, and not 3 months later when you don’t even remember what did you done
  • you will have an automated process for upgrading the server that guarantees everything is fine, which will save you time in the long term

The most important drawback is that implementing this kind of process has its associated costs (most of them in terms of time), but after thinking of it for a while, now it seems to me that the costs are not as high as one might think if you are already doing things right (as using a version control systems, having unit tests, integration tests, build system, and so on).

I’m probably missing some points here, but I think this is a great concept that could make a difference in a product.

Finally, I would like to say that I decided to write this post because I was thinking on implementing this concept into my typing tutor web as a way of automating deployments. I don’t have it yet implemented, but I have been thinking on how I would do it, and probably my next post would be the about how to do it in practice.

Really interesting links to read:

Other links:

Trackback URL

, , ,

  1. Ivan
    02/05/2009 at 12:22 pm Permalink

    Es un tema interesante. Algo así quiero implementar usando scripts y Git (ya sabes mi amor por este SCM).. cuando tenga tiempo y ganas 😛

    Como planeas hacerlo tu?
    Por cierto, deployment yo siempre lo he traducido por “despliegue”, pero se que no es una palabra demasiado acertada pq se suele usar sólo en entornos militares y ya sabes lo que suelen decir luego los talibanes lingüisticos cuando no usas exactamente como se debe una palabra.

  2. Pau Sanchez
    03/05/2009 at 12:51 am Permalink

    En el siguiente post contaré mas o menos lo que tengo pensado sobre esto, y así cada uno que aporte su visión 😉

    El problema de la gente “purista” (con cariño a todos vosotros), es que te critican y luego dicen cosas como “CD” cuando deberían decir DC (disco compacto) ;p

    De todos modos, yo me siento más cómodo llamando a las cosas por el nombre en el que las he aprendido: sistema de build, deployment, vcs (o scv), etc…

    Las fronteras del mundo cada vez son menores, es normal que las lenguas se mezclen, y al que no le guste, que estudie historia y verá como no es un tema nuevo 😉

  3. Ivan
    04/05/2009 at 2:30 pm Permalink

    Sinceramente, yo tambien prefiero el neologismo.. sin llegar al extremo de vacunar la carpeta 😉

  4. ray_iceman
    04/05/2009 at 3:26 pm Permalink

    Creo que la traducción más adecuada definitivamente es desplegar (desplegar la aplicación o desplegamiento de la aplicación). Al menos es la que yo ocupo cuando la traducción estrictamente lo amerita. Pero como dices, en el 99% de los casos estamos más que acostumbrados a la palabra en inglés y además casi siempre la utilizamos en un contexto donde hay gente que habla de lo mismo y sabe a que nos referimos.
    Respecto a las herramientas, al menos en mi caso que trabajo con Java, el caso mas simple es usando scripts con Ant, Maven y shell scripts (tambien uso otra herramienta llamada WLST que me permite hacer el deployment a servidores de weblogic). En la empresa donde trabajo contamos con otras herramientas mas complejas (en realidad en su interior tambien se basan en scripts simples). Una de ellas es Anthill Pro que está muy completa y te permite hacer pruebas (por ejemplo con JUnit), pero desafortunadamente tiene un costo. La otra es Hudson que es bastante similar y es open source. Como mencionas existen multiples ventajas. En nuestro caso el beneficio ha se traduce en un enorme ahorro de tiempo e incremento de la calidad pues los errores también salen a la luz rápidamente.

  5. Pau Sanchez
    05/05/2009 at 9:32 am Permalink

    Hola @ray_iceman, totalmente de acuerdo, desplegar probablemente sea la mejor traducción. Aunque al final, todos nos entendemos bien con el inglés.

    Sobre las herramientas que uso, dada mi situación actual de escasos recursos, y quitando Perforce, trato de usar herramientas gratuitas y/o opensource.

    Para el sistema de build, estoy usando Hudson junto con ant y phpunit para los tests. A parte, también tengo varias máquinas virtuales (con vmware) que corren selenium-rc/selenium-grid sobre windows/linux para pasar algunos tests.

    La verdad es que estoy bastante contento con Hudson, aunque si tubiera algo más de tiempo seguramente trataría de personalizar algunas cosas y de crearme algún plugin.

    Un saludo!

Trackbacks

  1. [...] en el artículo anterior hacía una introducción más detallada al tema de deployment/despliegue continuo, vuelvo a repetir el [...]