Ao implementar um novo recurso para um aplicativo que usa uma microarquitetura, geralmente você precisa fazer alterações em vários (micro) serviços. Normalmente, esses serviços também aproveitam a reutilização de código por meio de bibliotecas, tornando ainda mais provável o caso de você precisar tocar vários repositórios para implementar um único recurso.
Isso pode causar um problema com dependências. As alterações são feitas em seu sistema local para todas as bibliotecas e serviços e tudo funciona. A partir daí, você pode adicionar várias solicitações pull para os diferentes repositórios. Mas é aqui que se torna complicado. Se os PRs nas bibliotecas não forem mesclados primeiro e na ordem correta, os serviços podem ser interrompidos. Além disso, se os serviços não forem implantados ao mesmo tempo, eles podem não funcionar mais juntos.
Ao trabalhar com um sistema Agile como Scrum ou Kanban, podemos definir algumas regras para resolver isso.
- Cada tarefa DEVE entregar uma única solicitação de pull.
- Cada solicitação de pull DEVE ser mesclada independentemente.
Efetivamente, se uma tarefa também requer uma mudança em uma biblioteca ou outro aplicativo, uma tarefa adicional deve ser criada para ela.
As bibliotecas devem permanecer compatíveis com versões anteriores. Em vez de remover completamente um recurso, desative-o. Certifique-se de marcar esse código como obsoleto, tanto por meio de uma @deprecatedpropriedade no docblock quanto dando um aviso em tempo de execução. Tente manter os métodos BC, marcando essas partes do código. Se um método precisa ser alterado e não pode permanecer BC, adicione outro método e desative o antigo. O mesmo vale para propriedades e atributos.
Para serviços, isso é ainda mais importante. A API também deve permanecer compatível com versões anteriores. A funcionalidade deve ser descontinuada e disparar avisos. Os avisos darão uma ideia se e quanto a funcionalidade obsoleta ainda está sendo usada.
Idealmente, o lançamento de uma nova versão principal de uma biblioteca ou serviço seria apenas remover o código obsoleto e específico do BC.
Ao consumir bibliotecas e usar outras APIs, um serviço deve ser compatível com versões futuras. Deve depender e funcionar com uma versão mais antiga da biblioteca ou API. As dependências são atualizadas para uma versão mais recente da biblioteca, ela deve usar a funcionalidade mais recente. Para usar serviços externos, você pode fazer o mesmo verificando a versão da API.
Usar compatibilidade com versões anteriores e posteriores é a situação ideal. No entanto, às vezes isso simplesmente não é viável. Nesse caso, você só pode concluir uma tarefa e deve colocar a outra tarefa e / ou PR em espera até que o primeiro PR seja mesclado e liberado.