O objetivo final principal de uma pipeline de integração contínua é entregar um produto de software (realizar um deploy).
Visto isso, muitas vezes o desenvolvedor construirá jobs que executem uma aplicação em um certo ambiente, como desenvolvimento ou produção.
Para facilitar este processo, o GitLab possui a funcionalidade de ambientes.
Os ambientes do GitLab facilitam para que o desenvolvedor defina e documente quais os ambientes de uma aplicação.
Com eles, o desenvolvedor pode definir, em um job de deploy, por exemplo, em qual url a aplicação estará disponível, e em qual ambiente.
Para exemplificar, digamos que tenhamos o seguinte caso de uso:
- A aplicação tem dois ambientes:
- De testes, disponível na url http://test.com;
- De produção, disponível na url http://production.com.
- Deve ser possível parar o ambiente de testes manualmente;
- O deploy de testes deve ser feito automaticamente;
- O deploy de produção deve ser feito manualmente.
O desenvolvedor primeiro precisaria criar os ambientes na página do projeto no GitLab, e depois poderia adicionar esta especificação no arquivo gitlab-ci.yml:
stages:
- test_deploy
- production_deploy
start test server:
stage: test_deploy
script:
- start the test application...
environment:
name: development
url: http://test.com
stop test server:
stage: test_deploy
script:
- stop the test application...
when: manual
environment:
name: development
action: stop
start production server:
stage: production_deploy
script:
- start the production application...
environment:
name: production
url: http://production.com
Em cada job, está sendo indicado qual o ambiente que ele irá alterar, utilizando o valor environment
.
Jobs que param o servidor são definidos com action: stop
, e configurados para rodar manualmente.
Um ponto importante a ressaltar é que esta funcionalidade age apenas como um facilitador para administrar a documentar os ambientes da aplicação.
Toda a lógica da execução e deploy da aplicação deverá ser feita pelo desenvolvedor, no script do job relacionado!