fundo
Estou trabalhando em uma equipe que procura implementar implantações com tempo de inatividade zero. Planejamos usar uma estratégia de implantação azul / verde para conseguir isso. Uma das coisas que estou percebendo ao fazer a pesquisa é como fica complicado fazer alterações no banco de dados. Uma operação simples como renomear uma coluna pode levar três ciclos completos de lançamento até que seja concluída!
Parece-me que ter a distribuição completa de uma mudança leva vários ciclos de lançamento apresenta muito potencial para erro humano. No artigo vinculado, mostra que as alterações de código são necessárias para duas liberações e uma migração de banco de dados é necessária para três liberações.
O que estou olhando
Atualmente, se queremos lembrar de fazer algo, podemos criar um ticket em nosso sistema de gerenciamento de problemas, o que cria confusão e também pode ser movido para um sprint posterior ou para o backlog pela gerência; ou podemos criar um comentário TODO, que provavelmente será esquecido completamente.
O que estou procurando é uma maneira de um comentário TODO ter um prazo contra ele, e nosso sistema de Integração Contínua (atual indeciso que usaremos) rejeitaria a compilação se esse prazo expirasse.
Por exemplo, se renomearmos uma coluna, poderemos criar a migração inicial para ela e, em seguida, dois comentários TODO para garantir que as duas migrações restantes sejam criadas:
// TODO by v55: Create migration to move constraints to new column, remove references to old column in app
// TODO by v56: Create migration to drop old column
Isso parece bastante simples de implementar, mas estou me perguntando se algo assim já existe, porque não quero reinventar a roda.
Pensamentos adicionais
Sinto que posso estar sofrendo do problema XY aqui, dado que as implantações contínuas e as implantações azul / verde são consideradas uma prática recomendada, parece estranho que eu não consiga encontrar uma solução para tornar as atualizações do banco de dados menos dolorosas. Se você acha que estou analisando completamente a coisa errada, informe-me em um comentário! Dito isto, o exemplo do banco de dados que dei é apenas um exemplo, e acho que os comentários do TODO com datas de vencimento também seriam úteis em outras situações, portanto, mesmo que eu esteja me aproximando dessa situação específica de maneira errada, gostaria muito de responder às minhas perguntas. pergunta real também. Obrigado!
Edição: Acabei de pensar em outra situação em que isso poderia ser útil. Se você usar Alternâncias de recursos para ativar partes do seu aplicativo quando estiverem prontas, tenha cuidado para limpá-las; caso contrário, poderá acabar com Alternar dívida . Comentários com prazos podem ser uma boa maneira de lembrar disso.
TODO <Bug#>:
para rastrear soluções alternativas para problemas com outros componentes. Quando um bug é solucionado em um desses componentes, você pode encontrar e resolver facilmente as soluções alternativas relevantes. Ele não substitui um rastreador de problemas, facilita a manutenção.