Plataforma de Desenvolvimento Grupo Boticário
Como funciona a plataforma que acelera a criação de ambientes de desenvolvimento do Grupo Boticário.
Um dos grandes desafios das empresas de tecnologia está no ponto de início do ciclo de desenvolvimento de software, que é como criar toda a estrutura de um ambiente desde desenvolvimento até produção de uma maneira simples e rápida. Fazer o bootstrap de uma aplicação com todos seus pré-requisitos desde infraestrutura até observabilidade é essencial para que times de desenvolvimento tenham sucesso com entregas ágeis.
Mesmo que muitas empresas já tenham esses processos automatizados, notamos que muitas vezes desenvolvedores gastam uma parte relativa de seu tempo de trabalho em steps manuais escrevendo repetidos arquivos de configurações como YAMLs, JSONs, TFs(Terraform).
As empresas de tecnologia também já estão bem habituadas com pipelines de software CI/CD e provisionamento de infra como código, mas nota-se um ‘gap’ entre essas etapas para que o fluxo de uma aplicação funcione de forma íntegra e conjunta. O que vemos muitas vezes são steps de infra trabalhando separadamente dos steps de desenvolvimento, mesmo sabendo que a infra é um pré-requisito da aplicação.
Com todas essas observações, o time do GB começou a pensar em uma solução que não só fizesse um desenvolvedor subir uma aplicação em apenas alguns minutos até produção, mas também uma solução que o poupasse de etapas manuais e monótonas escrevendo arquivos de configurações.
Além de promover uma aplicação com todos os padrões de monitoramento e segurança, queríamos um fluxo que englobasse todos os pré-requisitos de uma determinada aplicação incluindo infraestrutura. E, por último, mas não menos importante, que o desenvolvedor tivesse autonomia para criar o que precisa, sem a necessidade de pedir permissão ou ajuda de alguma pessoa de outra área.
Com isso, nasceu a Plataforma de Desenvolvimento(PDD), onde juntamos algumas ferramentas e tecnologias que visam acelerar o desenvolvimento e facilitar o dia a dia do desenvolvedor.
Vou falar mais sobre como fizemos a construção desse projeto e como usamos cada uma das ferramentas que compõe a plataforma.
Ferramentas
Backstage: é uma plataforma open source que foi criada pelo Spotify e, posteriormente, foi doada para a CNCF. Foi criada para construir portais de desenvolvedores e catálogo de serviços.
Escrito em node, o Backstage é essencialmente a porta de entrada para a Plataforma De Desenvolvimento(PDD), é o primeiro contato do dev com a plataforma. É a nossa interface com o desenvolvedor, onde pode-se criar e administrar todas as aplicações de acordo com a necessidade. Entre outras coisas, ele atua como catálogo de serviços, disponibilizando os repositórios de cada aplicação com seus respectivos donos e mantenedores, onde é possível centralizar a documentação de cada aplicação e usar ou estender diversas integrações com Argocd, NewRelic e Sonar.
No mercado é comum vermos empresas utilizando o Backstage apenas como Catálogo de Serviço, aqui no PDD decidimos ir além dessa abordagem. Decidimos que a criação de toda aplicação e seus requisitos sejam feitos por dentro da própria plataforma, com isso, conseguimos entregar uma nova aplicação de forma rápida e com o mínimo de padronização, garantindo assim, que as aplicações criadas estejam em conformidade com as definições da empresa.
Assim, a partir de um formulário populado pelo desenvolvedor, o Backstage dá início à criação e configuração de tudo que compõe uma aplicação, como:
✓ criação e configuração do repositório
✓ configuração da pipeline
✓ configurações de integrações ex:(Newrelic, Sonar)
✓ configurações de objetos do k8s
✓ configuração da infraestrutura
Basicamente, todas as configurações mencionadas acima ficam em arquivos dentro do próprio repositório que foi criado, e claro, podem ser customizadas pelos desenvolvedores se necessário. Essas configurações vão sendo utilizadas por outras ferramentas a partir dos steps do pipeline de CI/CD, que é acionado assim que o repositório é criado.
GitHub Actions: ferramenta do próprio GitHub que permite customizar fluxos de trabalho dentro do repositório.
Optamos pela ferramenta por causa de sua integração e praticidade, uma vez que usamos o próprio GitHub.
Resolver todo o fluxo integrado com o próprio repositório faz uma grande diferença.
Porém, o fato de cada repositório ter seu próprio arquivo de configuração pode facilitar em alguns casos, mas pode virar um problema em outros. Por exemplo, manter um ciclo de atualização.
Imagina ter que corrigir um bug no workflow, repositório por repositório =s
Conseguimos contornar esse tipo de problema utilizando CustomActions, onde escrevemos actions personalizadas e referenciamos as mesmas dentro de cada repositório, mantendo assim somente um ciclo de atualização.
Decidimos também não usar muitas regras de negócio dentro do Actions, deixando assim, bem delimitadas as responsabilidades de cada ferramenta utilizada.
A grande responsabilidade do Actions é a parte de CI, uma vez que temos o ArgoCD pra fazer toda a parte de Delivery.
São de suma importância essas definições pois, se em algum futuro próximo quisermos migrar para outra ferramenta, esse processo fica bem mais fácil de se fazer com as responsabilidades bem definidas.
Voltando ao fluxo, uma vez que o Backstage cria o repositório da aplicação e escreve o arquivo de configuração ".github/workflows/standard.yaml " do Github Actions, ele assume o protagonismo e segue com os steps da pipeline
O processo de CI não tem muito segredo, tirando a parte de testes e compilação que varia de acordo com cada linguagem de programação (isso vai configurado a partir do template de cada linguagem, que é criado pelo Backstage), no mais o processo de CI resume em fazer o build de um dockerfile que fica no projeto e subir essa imagem para o Registry da AWS ECR.
ArgoCD + Helm: Argo é a ferramenta de GitOps queridinha do mundo Devops escrita em Golang que permite fazer entrega contínua com objetos kubernetes.
Helm é uma ferramenta de gerenciamento de pacotes para aplicações Kubernets. Ele usa um formato de pacotes chamado chart, um Helm chart é uma conjunto de arquivos que descrevem e definem objetos kubernetes.
Essas duas ferramentas são responsáveis pela parte de CD (Content Delivery) da plataforma.
Escrevemos um helm chart específico para criação das aplicações do Grupo Boticário: o gb-app.
Esse chart faz a abstração das configurações definidas para criar objetos kubernetes.
A ideia foi fazer um chart modular onde poderíamos ligar /desligar ou até mesmo adicionar features de acordo com a necessidade de cada aplicação.
Por exemplo, posso querer subir um disco adicional em uma determinada aplicação, ou querer alterar configurações de healthcheck, escolher se vou expor o endpoint publicamente ou não.
Com isso temos um único chart que se modela à maioria das aplicações, independente se ela for um simples job em bash, ou até mesmo uma aplicação backend em uma linguagem qualquer.
No exemplo acima temos a configuração de um webserver com Nginx.
HPA, serviço habilitado e exposto publicamente, healthcheck configurado, e a opção de um volume extra.
Neste outro exemplo temos uma simples aplicação python rodando um initcontainer copiando arquivos para um volume adicional.
A ideia foi deixar o mais dinâmico possível porque assim podemos aproveitar o chart para diversas aplicações.
Voltando para o fluxo, esse arquivo, que na verdade é o values.yaml do nosso chart, fica em uma pasta separada por ambientes dentro de cada aplicação.
Assim que step do Github Actions chega na etapa de CD, ele faz a comunicação com Argocd e é criada a aplicação usando helm chart gb-app com as configurações do arquivo.
Por fim, na etapa de CD temos o resultado de uma aplicação dentro da console web do próprio Argo mostrando todos objetos criados.
Crossplane: é uma ferramenta que permite a criação de recursos de infraestrutura em cloud por meio de objetos kubernetes.
A partir de CRDs, ele estende o kubernetes permitindo a criação de componentes de infraestrutura ou serviços nos principais provedores de cloud atuais.
Para compor a parte de infraestrutura dentro da Plataforma de Desenvolvimento, queríamos ir além de ter somente um step que rode a infraestrutura de forma automática por meios tradicionais com terraform ou ansible.
A ideia era trazer o provisionamento de infra pra dentro do fluxo de deploy da aplicação.
Se a infraestrutura é um pré-requisito da aplicação, porque não manter o ciclo de vida deles em conjunto?
Com o crossplane conseguimos fazer justamente isso, porque foi possível pegar a abordagem que acabamos de falar no tópico anterior sobre CD (com Argocd e helm), e colocar na pipeline para criação de infraestrutura, uma vez que podemos criar recursos de cloud com objetos kubernetes.
Da mesma forma que fizemos um chart para aplicações, o gb-app, construímos um chart para infraestrutura o gb-infra.
Assim como no chart de aplicações, o gb-infra também é modular, onde podemos criar/administrar um banco RDS mysql ou postgresql, tabelas dynamodb ou até mesmo um cloudfront com s3.
No arquivo acima temos a declaração de um RDS Mysql e uma tabela Dynamo.
Similar ao arquivo da aplicação, esse arquivo fica em uma pasta separada por ambientes dentro de cada repositório.
Ele é escrito pelo próprio backstage na etapa de criação da aplicação, e consumido pelo ArgoCD na pipeline do Github Actions.
Mantendo assim toda nossa gestão de infraestrutura separada por cada ambiente e aplicação dentro do ArgoCD.
Com isso, a Plataforma de Desenvolvimento garante um fluxo que engloba todos os pré-requisitos de uma aplicação do início ao fim.
Essa solução nos dá o poder de criar repositórios, pipelines, infraestrutura e mantém toda a configuração dentro do ciclo de vida de cada aplicação. Poupando a equipe de steps manuais e desconjuntas.
