Uma vez que a configuração da build tenha sido validada com sucesso, ela está apta a entrar na fila de deploy para ser instanciada no servidor remoto. Para o deploy não é necessário utilizar a dashboard da plataforma, sendo o processo executado diretamente pelo GitLab ou pelo cliente GIT de sua preferência. Conforme já visto, quando uma nova aplicação é adicionada na plataforma são criadas 4 (quatro) branches em seu repositório GIT: main, alpha, beta e release. Como detalhado no capítulo de introdução, a branch denominada “main” é o tronco (trunk) do repositório. As outras três branches são utilizadas pela o deploy de cada um dos estágios de maturidade da aplicação.
Assim, em linhas gerais, para realizar o deploy de uma build, bastará ao desenvolvedor realizar o merge da branch “main” para a branch do estágio da build e, em seguida, criar um tag com o número de versão da build.
Atenção! A tag com o número de versão da build deve ser criada a partir da branch de estágio (alpha, beta ou release).
A plataforma é criteriosa quanto ao formato do número de versão da tag. Já explicamos a sintaxe do número de versão no capítulo de introdução. Caso a versão não esteja no formato requerido ou a tag não seja originária da branch de estágio correlato, o deploy não será realizado.
Ao fazer o push da tag para a origin, o autômato irá detectar a nova versão e iniciar o processo de deploy no ambiente. Este processo envolve as seguintes etapas:
- Revalidação da build na versão específica;
- Criação da network da stack de containers;
- Criação dos volumes no servidor de storage;
- Backup dos dados da instância atual da build;
- Construção (p.e.,
docker compose build
) dos serviços da stack de containers; e - Inicialização (p.e.,
docker compose start
) dos serviços no cluster.
Atenção (a)! A execução do backup durante o processo de deploy (item 4) possui um tempo limite de 1 hora. Caso não seja concluído neste período, a execução do backup é interrompida, mas o processo de deploy continua.
Atenção (b)! A construção dos serviços (item 5) possui um tempo limite de 15 minutos. Caso não seja concluído neste período, o processo de deploy é interrompido e a build é marcada como inválida.
Um e-mail será enviado aos membros da equipe do projeto com os logs do processo executado, semelhante ao abaixo:
INFO > New tag found to build 'pbc/mobile@alpha'!
INFO > Updating from 2.22.5-alpha.4 to 2.22.5-alpha.5, commited by Camilo Carromeu <camilo.carromeu@embrapa.br> at 2022-06-13T09:34:57.000-04:00.
INFO > Checking if new tag has been created from branch 'alpha'... ok!
WARNING > No related milestone found! Has good practice, a milestone named '2.22.5' is required to manage issues releated to this release.
INFO > Trying to load '.embrapa/settings.json' from remote repository... done!
INFO > Trying to load metadata info...
INFO > Metadata info of boilerplates, clusters and types loaded!
INFO > New version will be deployed as 'container' using orchestrator 'DockerCompose' at server 'cluster.sede.embrapa.br'!
INFO > CI/DI environment variables:
COMPOSE_PROJECT_NAME=pbc_mobile_alpha
COMPOSE_PROFILES=alpha
IO_SERVER=cluster.sede.embrapa.br
IO_PROJECT=pbc
IO_APP=mobile
IO_STAGE=development
IO_VERSION=2.22.5-alpha.5
IO_DEPLOYER=camilo@carromeu.com
SENTRY_DSN=https://6389eb20b717423344fea535c489ef93@bug.embrapa.io/47
MATOMO_ID=2
MATOMO_TOKEN=e4c42495a19e1c63ecaa7e1c7285d599
INFO > Trying to clone app... done!
INFO > Checking SSH connection to host 'cluster.sede.embrapa.br'... ok!
INFO > Validating Docker Compose file:
COMMAND > env $(cat .env.io) DOCKER_HOST="ssh://root@cluster.sede.embrapa.br" /usr/bin/docker-compose config
INFO > Trying to validate declared VOLUMEs and PORTs...
INFO > All published PORTs are valid!
COMMAND > env $(cat .env.sh) DOCKER_HOST="ssh://root@cluster.sede.embrapa.br" /usr/bin/docker-compose config --services
WARNING > Some CLI recomended services are NOT FOUND at docker-compose.yaml: restore, sanitize, test! Please, check configuration.
WARNING > File docker-compose.yaml is VALID, but has some alerts to fix!
INFO > Trying to execute backup service before deploy...
COMMAND > env $(cat .env.sh) DOCKER_HOST="ssh://root@cluster.sede.embrapa.br" /usr/bin/docker-compose build --force-rm --no-cache backup
COMMAND > env $(cat .env.sh) DOCKER_HOST="ssh://root@cluster.sede.embrapa.br" /usr/bin/docker-compose run --rm --no-deps backup
Creating pbc_mobile_alpha_backup_run ...
Creating pbc_mobile_alpha_backup_run ... done
SUCCESS > Backup service executed successfully!
INFO > Building application with Docker Compose...
COMMAND > set -e && env $(cat .env.io) DOCKER_HOST="ssh://root@cluster.sede.embrapa.br" /usr/bin/docker-compose up --force-recreate --build --no-start && echo "Exit code: $?"
Successfully built c0ddfaae85a5
Successfully tagged pbc_mobile_alpha_pwa:latest
Exit code: 0
INFO > Getting valid services (will ignore: backup, restore, sanitize, test)...
COMMAND > env $(cat .env.io) DOCKER_HOST="ssh://root@cluster.sede.embrapa.br" /usr/bin/docker-compose config --services
INFO > Starting application with Docker Compose...
COMMAND > env $(cat .env.io) DOCKER_HOST="ssh://root@cluster.sede.embrapa.br" /usr/bin/docker-compose start pwa
SUCCESS > All done! Version '2.22.5-alpha.5' in 'alpha' stage of application 'pbc/mobile' is DEPLOYED!
INFO > The following PORTs have been exposed:
https://cluster.sede.embrapa.br:49155 [https://test.sede.embrapa.br/pbc]
Pela dashboard da plataforma todos os membros da equipe podem acompanhar as versões instanciadas de cada build. Pelo card é possível também acessar a instância por meio dos links para as portas expostas publicamente.
Os membros da equipe do projeto poderão agora, pelo card da aplicação, monitorar a instância da build e gerenciá-la.