Merge Request

Um dos objetivos da plataforma Embrapa I/O é fomentar o desenvolvimento colaborativo junto à comunidade de desenvolvedores. Assim, os artefatos de software que compõem os projetos são, em grande parte, forks de repositórios-base no GitLab da plataforma.

Esta estratégia possibilita que qualquer problema encontrado nas derivações destes repositórios (seja no momento de desenvolver uma aplicação, ou quando estiver customizando um repositório de suporte) possam ser corrigidos pela própria equipe que identificou o problema e, em seguida, retroalimentar o repositório-base, corrigindo o problema também em sua origem. A partir daí, todos os demais repositórios que foram derivados a partir desta origem, poderão também ser corrigidos por um processo simples de merge no GIT.

Para demonstrar como isso pode ser realizado, vamos exemplificar por meio de um estudo de caso. Imagine que, ao tentar realizar o processo de backup por demanda em uma build denominada agroapp/api@alpha, o seguinte erro tenha sido emitido:

COMMAND > env $(cat .env.sh) DOCKER_HOST="ssh://root@cluster.agro.rocks" /usr/bin/docker-compose run --rm --no-deps backup
sh: syntax error: unexpected "&&"
CRITICAL > Impossibe to backup build. Backup service failed to RUN!

Ao observar o arquivo docker-compose.yaml na raiz do repositório é possível constatar que o atributo command no serviço backup do stack de containers está implementado de forma errônea:

backup:
  build:
    context: .
    dockerfile: ./docker/${ENVIRONMENT}/backup/Dockerfile
  restart: "no"
  depends_on:
    - db
  links:
    - db
  volumes:
    - data_backup:/backup
  command: >
    sh -c  "set -ex
      && export BACKUP_DIR=${COMPOSE_PROJECT_NAME}_${STAGE}_$$(date +'%Y-%m-%d_%H-%M-%S')
      && cd /backup && mkdir $$BACKUP_DIR
      && mongodump --host db --username root --password ${MONGO_ROOT_PASSWORD} --authenticationDatabase admin --out /backup/$$BACKUP_DIR/db
      && tar -czf $$BACKUP_DIR.tar.gz $$BACKUP_DIR
      && rm -rf /backup/$$BACKUP_DIR"
  profiles:
    - cli

Uma vez que este erro é originário do boilerplate, iremos realizar a correção de forma que, posteriormente, possamos sugerí-la também ao repositório-base. Para isso, precisamos primeiro criar uma branch de correção, que deverá ser uma ramificação da main a partir do commit imediatamente anterior ao fork do repositório-base. Para criar esta branch, primeiramente acesse o histórico de commits do repositório:

Em seguida, procure na listagem de commits por uma entrada denomidada “Configuração inicial automática do repositório.”, submetida pelo usuário “embrapa.io Genesis Automaton” e copie o Commit SHA do commit realizado imediatamente antes desta entrada:

Agora, crie uma nova branch utilizando este commit como base:

Utilizando um cliente GIT ou a própria interface do GitLab, faça o checkout para esta nova branch, efetue as correções no código-fonte e realize o commit:

Faça agora o merge da sua branch de correção para o troco do projeto (main). Teste em ambiente de desenvolvimento. Estando tudo certo, faça o merge da main para a branch de estágio alpha e realize o deploy criando uma nova tag. No nosso exemplo, uma vez que o deploy da build agroapp/api@alpha tenha sido realizado com sucesso, iremos testar novamente o serviço de backup diretamente no ambiente de testes internos.

Uma vez que esteja tudo funcionando corretamente, iremos realizar um merge request da nossa branch de correção para o repositório-base (ou seja, do boileplate), que no nosso estudo de caso é io/boilerplate/nodejs-mongodb-jwt-password-less (veja a primeira imagem desta página). Para isso, crie um merge request tendo como source a branch de correção e como target o tronco do repositório do boilerplate:

Pronto! Um mantenedor do boilerplate poderá agora avaliar as alterações, aprovar e realizar o merge no repositório-base. Isto permitirá também a outros desenvolvedores que tenham aplicações derivadas do mesmo boilerplate aplicarem as correções.