Rastreando efetivamente as alterações na configuração de dev para prod

Esta pergunta usa um serviço Spring Boot como exemplo, mas poderia ser qualquer tecnologia.

Supondo o seguinte:

• Os ambientes (dev / QA / prod) pertencem a equipes diferentes. Isso significa que o dev não deve ter acesso à configuração do prod.
• A configuração (digamos application.properties) é externalizada, ou seja, não faz parte do binário
• O mesmo binário / pacote (digamos service.jar) é implantado em cada ambiente e controlado pela implantação automatizada

Embora as alterações no artefato binário (service.jar) sejam propagadas automaticamente para cada ambiente, as alterações na configuração ainda precisam de intervenção manual, que inevitavelmente acaba sendo dessincronizada em cada ambiente.

Por exemplo, digamos que a equipe dev adicione alguns pares de valores-chave ao application.properties em seu ambiente. Qual seria a melhor maneira de registrar essas novas chaves, para que, quando a implantação ocorra na equipe de operações, eles saibam exatamente quais chaves adicionar, para minimizar o risco de iniciar o novo serviço e vê-lo falhar por falta de uma chave?

Sei que haverá etapas manuais envolvidas, mas gostaria de saber como as pessoas lidam com isso e encontrar a maneira mais eficaz.

Isso é principalmente um problema de comunicação, mas você pode cometer erros menos prováveis ​​com algumas medidas técnicas e organizacionais simples. Primeiro, você deve fornecer uma documentação de alta qualidade de todas as entradas em seus arquivos de configuração, bem como algum exemplo facilmente acessível ou arquivo de configuração "padrão". O arquivo de exemplo pode ser implantado automaticamente em cada ambiente, pois não se destina a ser alterado diretamente pela equipe do produto.

Em seguida, a cada nova versão, forneça um registro de alterações, onde mudanças importantes são documentadas. As alterações na configuração que podem impedir o funcionamento do sistema quando estão ausentes são sempre importantes, portanto, verifique se as informações estão lá.

Por exemplo, digamos que a equipe dev adicione alguns pares de valores-chave ao application.properties em seu ambiente. Qual seria a melhor maneira de registrar essas novas chaves, para que, quando a implantação ocorra na equipe de operações, eles saibam exatamente quais chaves adicionar, para minimizar o risco de iniciar o novo serviço e vê-lo falhar devido à falta de uma chave?

A melhor maneira de reduzir o risco de falha é evitar alterar seu aplicativo de uma maneira que exija as novas chaves, para que o aplicativo seja compatível com os arquivos de configuração mais antigos sempre que possível. Geralmente, seu aplicativo pode se comportar de maneira sensata, fornecendo valores padrão embutidos para as novas chaves para o caso em que elas estão ausentes.

No entanto, se isso não for possível, seu sistema deve tornar o mais fácil possível para a equipe de produtores descobrir por que o novo serviço falha ao iniciar quando a chave está ausente. Deve haver uma mensagem de erro clara, informando exatamente qual chave está faltando em qual arquivo e, se necessário, onde encontrar as informações sobre a chave ausente, ou uma dica ou exemplo sobre uma entrada significativa para essa chave.

Se a configuração for complexa e o formato mudar de maneira que a edição manual se torne propensa a erros, considere também fornecer ferramentas para editar as configurações e migrar para uma versão mais recente.

Por exemplo, estou usando o navegador Firefox e, a cada nova versão (que eu recebo automaticamente), algumas coisas são adicionadas à configuração local que se pode inspecionar na página "about: config". Isso é comparável à configuração no seu ambiente de "produção". Como toda a configuração é mantida estritamente compatível com versões anteriores, nunca preciso adicionar novas chaves manualmente à configuração apenas porque existe uma nova versão do navegador. E, no caso, eu quero mudar alguma coisa lá (talvez uma nova entrada que não fazia parte da versão anterior), eu uso o menu Ferramentas / Opções ou a página "about: config" e posso encontrar a entrada mais algumas tipo de documentação. Portanto, recomendo tentar implementar seu sistema de maneira comparável.

Em um lugar em que trabalhei, eles tiveram um problema semelhante. A configuração da produção foi controlada pela equipe de criação, apenas eles tiveram acesso a ela no repositório de códigos. As configurações dev, qa, test, etc ... podem ser vistas por todos.

No seu exemplo, um desenvolvedor atualizava o arquivo localmente, fazia check-in no controle de origem e alguém solicitava à equipe de criação que fizesse uma nova compilação "config only" que efetuou check-out dos arquivos de configuração e os implantou, mas não recompilou ou reimplemente o aplicativo inteiro.

Cabia aos membros da equipe atualizar os arquivos de configuração para outros ambientes no momento apropriado. Quando chegou a hora de atualizar para produção, a equipe de construção teve que atualizar o arquivo, através de uma solicitação explícita do líder da equipe de desenvolvimento, embora geralmente a solicitação simplesmente parecesse "copiar o arquivo app.config do QA1 para o PROD". Itens sensíveis, como senhas, estavam em um arquivo de configuração separado e, novamente, apenas a equipe de construção pôde acessar o arquivo de senha de Produção. A diferença era que os desenvolvedores geralmente nãosolicitar alterações nos arquivos de senha porque eles não teriam senhas de produção. A única vez em que eles pediram à equipe de construção que o atualizasse foi ao adicionar uma nova senha para um novo serviço. E mesmo assim, os desenvolvedores provavelmente não saberiam a senha de produção, apenas saberiam a chave a ser adicionada ao arquivo (como "newService2.password").

A tecnologia usada para gerenciar muito disso era Jenkins. Havia também uma ferramenta interna usada para solicitar e agendar compilações por meio do Jenkins.