How to get to Continuous Deployment

In this guide, we will assume that your continuous integration and continuous delivery workflow is already in place and that your next step is to set up your continuous delivery pipeline.

Sten Pittet Sten Pittet

Ainda, confira nosso tutorial sobre como começar a usar Implementação contínua no Bitbucket Pipelines.

"Nobody touch production – I'm about to release!"

That phrase may be familiar to you. Deploying to production can be a risky and costly exercise that sometimes requires putting all development on hold. This causes release cycles to be slow and changes to stagnate in the development environment. It's the start of an awkward (and vicious) circle in which the more commits are made to the repository, the more risks get introduced into the next deployment to production, and the less likely your team is to make that release.

A implementação contínua resolve esse problema enviando automaticamente cada alteração enviada por push ao repositório principal para produção. É uma abordagem radical, muito diferente de gastar dias preparando e controlando cada versão, mas há diversos benefícios na implementação contínua:

  • Releases become smaller and easier to understand.
  • No one is required to drop their work to make a deployment because everything is automated. 
  • The feedback loop with your customers is faster: new features and improvements go straight to production when they're ready.

Pode ser bastante assustador passar de lançamentos aprovados para implementação contínua, mas este guia está aqui para ajudá-lo a fazer essa transição. Cobrimos as bases para que você possa começar assim que possível e passar a acelerar seu ciclo de lançamento.

Continuous deployment vs. continuous delivery

If you want to implement a continuous deployment pipeline, the best place to start with continuous delivery. These two practices are similar, but differ in their approaches to production deploys. In continuous delivery, every change pushed to the main repository is ready to be shipped, but the production release process still requires human approval. In continuous deployment, the release to production is done automatically for every change that passes the test suite.

Continuous delivery vs continuous deployment

Before you start shipping changes automatically to production, you'll need to have a good continuous integration (CI) culture, and it's highly recommended to start with continuous delivery first. You can read more about the two practices in the articles below:

Moving from continuous delivery to continuous deployment

Emphasize a culture of continuous integration

No centro da implementação contínua está uma grande cultura de CI. A qualidade do seu pacote de teste determinará o nível de risco da sua versão, e sua equipe precisará dar prioridade a testes automatizados durante o desenvolvimento. Isso significa implementar testes para cada novo recurso, bem como adicionar testes para qualquer regressão descoberta após o lançamento.

Fixing a broken build for the main branch should also be first on the list. Otherwise, you'll be exposing yourself to the same risks you faced prior to adopting continuous deployment: changes are accumulated in the development environment, and developers can't be sure that their work is finished as they don't know if their changes passed the acceptance tests.

Make sure you have good test coverage (and good tests too!)

Start using test coverage tools to make sure that your application is adequately tested. A good goal is to aim for 80% coverage.

Be careful not to mistake good coverage for good testing. You could have 100% test coverage with tests that don't really challenge your codebase. Make sure to spend time during code reviews to check how tests are written and don't hesitate to point out gaps in coverage or weak tests. Your test suite acts as the gate to production – make it a strong one.

Adopt real-time monitoring

Se você for implementar cada confirmação automaticamente em produção, precisará garantir que tenha uma boa maneira de ser alertado se algo der errado. Às vezes uma nova alteração não causará uma falha na produção de imediato, mas fará sua CPU ou consumo de memória subir a níveis perigosos. Por isso, é útil implementar monitoramento em tempo real em seus servidores de produção para conseguir rastrear irregularidades em suas métricas.

Tools like Nagios or services like New Relic can help you track basic performance metrics and alert you whenever there's a disturbance in your systems.

Revise seus testes pós-implementação

Depois de cada implementação na produção, você deve executar alguns testes de sanidade simples para garantir que o aplicativo esteja ativo e em execução.

Make sure that these tests do more than just hitting a static page, waiting for a success response. It's good practice to have a test that requires that all your production services (database, micro-services, 3rd parties...) are working properly.

Get your QA team to work upstream

As every commit goes now straight to production, it means that there's no traditional buffer for your QA to review and approve new features. Instead, they should be working closely with the product manager and the development team to define the risks associated with new improvements.

This is a great opportunity for the QA team as it will result over time in better quality for the releases. With continuous deployment, your team will be naturally inclined to have good test coverage of the codebase. Failing to do so means frequent disruptions due to bugs slipping out to production where they're discovered by your users.

Drop the traditional release notes

Continuous deployment makes it hard for you to keep up with releases – and that's a good thing! Your goal should be to have daily deployments to production, even multiple deployments per day. It may be bug fixes, small improvements, new features... whatever. As soon as a developer finishes their work, that work should be running in production in a matter of minutes.

In this new world it's no longer possible to write release notes that get sent to your customers with each new version. Instead, embrace this new flow and limit your announcements to key features that matter to your customers. Bug reports and small improvement requests can simply be handled in your ticketing system – JIRA, for instance, can update all watchers of a ticket as soon as you close or update it.

A different approach for new projects: deploy to production before coding

There's something interesting that you can do if you're getting started on a brand new codebase. You can start by creating your continuous deployment pipeline before having any customers and any feature ready (not unlike test-driven development). At the beginning, you'll be shipping an empty platform. Then, as development progresses, new capabilities will start appearing automatically. You just need to keep your production environment closed until you're ready to open it up for your customers.

This approach may seem counter-intuitive at first. But it's an easy way to take the stress out of going from a manual release approval to continuously deploying to production. It's also an excellent way to make sure that you have a good test coverage and continuous integration culture at launch since they necessary conditions for continuous deployment.

Amplie seu conhecimento e compartilhe sua experiência!

It's understandably hard to take the leap and switch to continuous deployment. All of a sudden the gates are lifted, and code goes straight to the customers in a matter of minutes or hours. (Eep!) So it's important to invest in the tests and automations that give you confidence in your builds. This will be easy if your codebase is new, but it may require adopting a different strategy for a complex ledgacy codebase.

Start small and build up your continuous deployment knowledge and experience. Once you get there for one project, it will be easy to replicate your success in other parts of your organization.