Close

Integración continua, entrega contigua e implementación continua

Descubre las diferencias entre estas prácticas continuas

Sten Pittet headshot
Sten Pittet

Contributing Writer


CI y CD son dos acrónimos que se utilizan con frecuencia en las prácticas de desarrollo actuales y DevOps. “CI” son las siglas de “integración continua”, una práctica fundamental recomendada de DevOps en la que los desarrolladores fusionan con frecuencia los cambios de código en un repositorio central donde se ejecutan compilaciones y pruebas automatizadas. Sin embargo, “CD” puede significar “entrega continua” o “implementación continua”.

¿Qué diferencias hay entre la integración continua, la entrega continua y la implementación continua (CI/CD)?


Continuous integration

Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch.

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

Continuous delivery

Continuous delivery is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage.

This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button.

In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

Ver la solución

Desarrolla y pon en marcha software con Open DevOps

Related material

What is the DevOps pipeline?

Continuous deployment

¿Cómo se relacionan las prácticas entre sí?


Dicho en pocas palabras, la integración continua forma parte tanto de la entrega continua como de la implementación continua. Además, la implementación continua es como la entrega continua, salvo en que las versiones que se publican de forma automática.

Differences between continuous integration, continuous delivery, and continuous deployment

¿Cuáles son las ventajas de cada práctica?


What are the benefits of each practice?

We've explained the difference between continuous integration, continuous delivery, and continuous deployments but we haven't yet looked into the reasons why you would adopt them. There's an obvious cost to implementing each practice, but it's largely outweighed by their benefits.

Continuous integration

What you need (cost)

  • Your team will need to write automated tests for each new feature, improvement or bug fix.
  • You need a continuous integration server that can monitor the main repository and run the tests automatically for every new commits pushed.
  • Developers need to merge their changes as often as possible, at least once a day.

What you gain

  • Less bugs get shipped to production as regressions are captured early by the automated tests.
  • Building the release is easy as all integration issues have been solved early.
  • Less context switching as developers are alerted as soon as they break the build and can work on fixing it before they move to another task.
  • Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.
  • Tu equipo de control de calidad dedica menos tiempo a las pruebas y puede centrarse en mejoras significativas de la política corporativa de calidad.

Continuous delivery

What you need (cost)

  • You need a strong foundation in continuous integration and your test suite needs to cover enough of your codebase.
  • Deployments need to be automated. The trigger is still manual but once a deployment is started there shouldn't be a need for human intervention.
  • Your team will most likely need to embrace feature flags so that incomplete features do not affect customers in production.

What you gain

  • The complexity of deploying software has been taken away. Your team doesn't have to spend days preparing for a release anymore.
  • You can release more often, thus accelerating the feedback loop with your customers.
  • There is much less pressure on decisions for small changes, hence encouraging iterating faster.

Continuous deployment

What you need (cost)

  • Your testing culture needs to be at its best. The quality of your test suite will determine the quality of your releases.
  • Your documentation process will need to keep up with the pace of deployments.
  • Las marcas de función se convierten en una parte inherente del proceso de publicación de cambios significativos para asegurar que puedes coordinarte con otros departamentos (soporte, marketing, RR. PP., etc.).

What you gain

  • You can develop faster as there's no need to pause development for releases. Deployments pipelines are triggered automatically for every change.
  • Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.
  • Customers see a continuous stream of improvements, and quality increases every day, instead of every month, quarter or year.

One of the traditional cost associated with continuous integration is the installation and maintenance of a CI server. But you can reduce significantly the cost of adopting these practices by using a cloud service like Bitbucket Pipelines which adds automation to every Bitbucket repository. By simply adding a configuration file at the root of your repository you will be able to create a continuous deployment pipeline that gets executed for every new change pushed to the main branch.

A continuous deployment pipeline with Bitbucket

Going from continuous integration to continuous deployment


Si acabas de empezar en un nuevo proyecto que todavía no tiene usuarios, puede resultarte sencillo implementar cada confirmación en la producción. Incluso podrías empezar automatizando tus implementaciones y publicando tu versión alfa en una producción sin clientes. A continuación, puedes aumentar tu política corporativa de pruebas y asegurarte de aumentar la cobertura de código al compilar tu aplicación. Cuando ya puedas incorporar a usuarios, contarás con un gran proceso de implementación continua en el que se someten a pruebas todos los cambios nuevos antes de publicarlos automáticamente en la producción.

Sin embargo, si ya cuentas con una aplicación con clientes, debes frenar el ritmo y comenzar con la integración y la entrega continuas. Empieza implementando pruebas unitarias básicas que se ejecuten automáticamente sin tener que concentrarte aún en ejecutar pruebas de extremo a extremo complejas. En lugar de ello, debes probar a automatizar tus implementaciones lo antes posible y llegar a una fase en la que las implementaciones se realicen automáticamente en tus entornos de ensayo. El motivo es que, si cuentas con implementaciones automáticas, podrás centrar tu energía en mejorar las pruebas en lugar de tener que detener las cosas periódicamente para coordinar una publicación.

Una vez que puedas publicar software a diario, puedes revisar la implementación continua, pero debes asegurarte de que el resto de tu organización (documentación, soporte, marketing, etc.) también esté listo. Estas funciones tendrán que adaptarse a la nueva cadencia de publicaciones, y es importante que no se pierdan cambios significativos que puedan afectar a los clientes.

Lee nuestras guías


Read our guides

You can find some guides that will go more in depth to help you getting started with these practices.

Sten Pittet
Sten Pittet

Llevo 10 años en el negocio del software desempeñando diversas funciones, desde el desarrollo hasta la gestión de productos. Tras pasar los últimos 5 años en Atlassian trabajando en herramientas para desarrolladores, ahora escribo sobre compilación de software. Fuera del trabajo, me dedico a perfeccionar mis habilidades como padre con el maravilloso hijo que tengo.


Share this article

Recommended reading

Bookmark these resources to learn about types of DevOps teams, or for ongoing updates about DevOps at Atlassian.

Devops illustration

DevOps community

Devops illustration

Leer el blog

Map illustration

Get started for free

Sign up for our DevOps newsletter

Thank you for signing up