Fluxo de Trabalho
Utilizamos o conceito de repositórios para fazer a gestão dos artefatos dos ambientes Smart. Para isto, utilizamos duas "lanes" de automação distintas. Uma para a montagem das imagens Docker e outra para a montagem dos charts. Após a compilação de todos os artefatos, nossos scripts iniciam e/ou disponibilizam a versão para que façamos a atualização nos ambientes. Segue o modelo utilizado:
Fluxo de tabalho - GIT
Para mantermos as imagens e os charts em conformidade com as práticas de mercado, utilizamos um fluxo de trabalho baseado no GitFlow. Os repositorios que utilização são o do AzureDevops (engpro-sre-images) e AzureDevops (engpro-sre-apps). Maiores informações sobre esse fluxo podem ser encontradas no link Fluxo de trabalho de Gitflow.
No caso de máquinas Windows, será necessário ter os executáveis do Git na máquina. Para SO Linux talvez seja necessário a instalação de um pacote separado. Nos OSX por exemplo você executa o comando brew install git-flow.
O importante nesse fluxo é combinar com a equipe o que se enquadra em desenvolvimento, hotfixes, recursos, releases e versões.
Basicamente no momento do checkout, utilizamos comandos diferentes que encapsulam os comandos básicos do Git e organizam os diferentes tipos de ajustes no código, gerando um novo branch.
Pull Request
Para commitar ajustes nos fontes nas branches principais, utilizamos os PRs (Pull Requests) para aprovação. A quantidade de aprovadores e que, serão eles, podem variar entre as branches develop e master.
Processo de trabalho
- Clonar o repositório AzureDevops (engpro-sre-images e engpro-sre-apps).
- Dentro do diretório local execute o comando git flow init
- Informe quais as branches principal e de integração (next release). Respectivamente main e develop. As outras perguntas pode deixar os valores default.
- Para iniciar os trabalhos numa melhoria de código execute o comando git flow feature start <nome do novo branch>
Faça seu trabalho normalmente fazendo seus commits como sempre na branch até o momento do merge com a branch develop.
Nesse momento não use nenhum dos comandos do git flow para finalizar a branch de feature. Inicie o processo de pull request e aguarde as aprovações do mesmo.
Não esquecer de avisar o time para realizar a aprovação. |
Quando o pull request for totalmente aprovado, você poderá fazer o merge, marcando a branch para ser apagada durante o merge.
Ao realizar o push, os jobs do Jenkins/Drone e/ou do cloudbuild entrarão em ação e iniciarão a build do processo commitado.
Calendário de Atualização
| Segunda | Terça | Quarta | Quinta | Sexta | |
|---|---|---|---|---|---|
| Expedição Backoffice | Atualização do chart nos clusters | Acompanhamento com o time de SRE | Geração das imagens e Charts contendo as correções expedidas pelo time de backoffice + rh | Homologação pelos times de produto em ambiente pré-produção das expedições geradas | Geração das releases a serem aplicadas em produção. |
| Expedição Padrão | Sem atividade | Geração das imagens e Charts contendo as correções expedidas pelos times de produto Homologação pelo time de SRE das correções aplicadas dentro do ambiente. |