A organização atual do código e da configuração que você descreve é estruturada pelas soluções técnicas envolvidas. Esse é um design ruim que adicionará muita sobrecarga em nossas atividades de manutenção e também incluirá muitas armadilhas em nosso caminho. Em vez disso, essa organização deve ser estruturada em torno dos artefatos que estamos implantando.
A razão para isso é que queremos considerar artefatos ( por exemplo, uma imagem do docker ou um pacote de software) como os objetos dos seguintes verbos:
- Construir
- teste
- implantar
considerar um conjunto mínimo de tarefas automatizadas que queremos executar. Se quisermos mudar algo sobre como o verbo de teste é implementado, é fácil visitar a pasta correspondente a esse artefato no repositório apropriado e descobrir os itens de automação específicos de jenkins que precisam ser atualizados. Em vez disso, se as receitas de automação são estruturadas em torno de soluções técnicas, precisamos descobrir do nada que jenkins está envolvido nos procedimentos de teste e encontrar lá os itens de automação relacionados ao artefato. Em situações complexas, a organização em torno das soluções técnicas dificulta muito as atualizações, porque precisamos conhecer a priori todas as soluções técnicas envolvidas em algum serviço para atualizá-las adequadamente.
Por exemplo, um repositório contendo o código de um site e um microsserviço "a" pode ter os seguintes subdiretórios dedicados às operações:
./ops/website
./ops/micro-service-a
cada um com três roteiros chamado build, teste deploy. Agora que a organização dos itens de automação foi esclarecida de alguma forma, vamos voltar nossa atenção para a configuração.
As principais condições e requisitos sobre a organização de configuração são definidas pelo deployverbo quando aplicadas a um artefato semelhante a um serviço. O deployverbo deve ter os seguintes parâmetros:
- a versão do artefato a ser implantada,
- o destino de implantação do artefato, que descreve o ambiente concreto em que o artefato implantado será executado ( por exemplo, um cluster e pontos de extremidade com os quais deve conversar)
- as credenciais que ele deve usar para se conectar a outros pontos de extremidade ( por exemplo, bancos de dados)
- a configuração de tempo de execução de (por quanto tempo as entradas de cache devem permanecer, etc.)
Da perspectiva operacional, esse detalhamento da parametrização corresponde aos graus naturais de liberdade do problema de implantação - além das credenciais que podem ser incluídas na configuração do tempo de execução, mas é melhor separá-las para evitar espalhá-las descuidadamente.