Controle de origem: Papéis e responsabilidades - Melhores práticas

Estou procurando "Boas Práticas" em relação a funções e responsabilidades, especificamente quem é responsável pelas fusões dos ramos de desenvolvimento ao tronco (ou principal). Basicamente, estou procurando munição para ajudar minha causa.

Deixe-me descrever o que estou enfrentando. Sou o desenvolvedor líder (proprietário) de um aplicativo específico. Nossa empresa mudou recentemente do VSS (onde eu era o administrador do banco de dados VSS no qual meu aplicativo estava armazenado) para o TFS (onde eu só tenho permissões nos ramos de desenvolvimento criados por nossa equipe de "operações"). Em trabalhos anteriores, eu era um administrador do TFS, por isso conheço o TFS e o MSBuild.

Não tenho problema com a estratégia de ramificação e mesclagem sendo usada (ramificação principal, com ramificações de desenvolvimento de bug / projeto criadas conforme necessário, mescladas de volta à main e depois promovidas a uma ramificação de lançamento). Os problemas que tenho são:

1. Não consigo criar meus próprios galhos. Preciso criar uma tarefa TFS para que um membro da equipe "operações" crie a ramificação para mim.

2. Não consigo mesclar do Main ao meu ramo de desenvolvimento. Preciso criar uma tarefa TFS para que um membro da equipe de "operações" realize a mesclagem e espero que ele não "pise" em nenhuma das minhas equipes, pois o "ops guy" pode ou não ser um desenvolvedor e certamente tem pouco ou nenhum conhecimento do código que ele está mesclando.

3. Não consigo mesclar do desenvolvimento para o Main. Novamente, preciso criar uma tarefa TFS para que o "ops guy" execute a mesclagem, esperando que ele faça isso corretamente. Em seguida, tenho que criar outra tarefa TFS para mesclar de volta para minha ramificação, para que eu possa resolver qualquer problema que tenha ocorrido ao mesclar um não desenvolvedor ao Main.

4. Não consigo criar ou editar scripts do MSBuild. Novamente, tenho que trabalhar com a equipe "ops", que é nova no MSBuild, para que apenas as tarefas mais básicas de compilação possam ser executadas. (Esqueça qualquer coisa complexa ou proíba uma tarefa personalizada).

5. Não consigo executar um script MSBuild. Novamente, apenas a equipe "ops" pode fazer isso.

6. Além disso, normalmente é um recurso "offshore" que executa as tarefas solicitadas, portanto, mesmo se eu criar a tarefa para (ramificação / mesclagem / construção) no início da manhã, provavelmente não será concluída até aquela noite.

Agora não tenho problemas com a equipe de "operações" mantendo as ramificações de liberação. Como tudo o que eles estão fazendo é (basicamente) pegar a versão mais recente do Main e promovê-la para o ramo de lançamento; enquanto "Main" estiver estável e pronto, o ramo de lançamento será bom.

Minha opinião é que os líderes técnicos (como eu) devem ser responsáveis ​​por manter o tronco ("Principal") e qualquer fusão de / para os ramos de desenvolvimento. O líder da equipe também deve ter a capacidade de gerar scripts do MS Build para criar e implantar no ambiente de teste de integração.

Alguém pode me direcionar para um documento de práticas recomendadas que me ajudará a provar meu caso? Toda a minha pesquisa revelou apenas as Melhores Práticas relativas às técnicas de ramificação e fusão, e nenhuma menção à OMS deveria estar realizando a ramificação / fusão.

Minha opinião geral sobre as práticas recomendadas é que qualquer membro da equipe de desenvolvimento deve ser capaz de executar qualquer ação na árvore, presumindo que essas ações não façam coisas como iniciar uma implantação de produção. Nos casos em que uma ramificação / tag / repositório específico atua como uma fonte para implantações automatizadas, colocar algum controle de mudança razoável ou barreiras à entrada faz sentido, mais do que manter erros, apenas erros de perspectiva, do que algum ângulo de controle e aberração. Eu incentivaria os desenvolvedores a criar ramificações e melhorar os scripts de construção. Eu encontraria maneiras de obter acesso de desenvolvedores à produção, se necessário. Parte do ponto de controle da fonte é que ele é um apagador mágico eficaz de erros - o pior que você precisa fazer é reverter uma ou duas rotações e ramificá-la.

Infelizmente, isso não soa como a abordagem que eles adotaram aqui. Para derrotar isso, acho que você precisa cobrir alguns ângulos:

a) Prove que essas políticas são prejudiciais ao desenvolvimento de coisas. Registre todo o tempo que você gasta esperando nas operações para trabalhar em algo. Isso por si só deve vender um gerenciamento razoável sobre por que essa é uma política ruim.

b) Faça alguns amigos no Ops - talvez haja uma razão para essa política. Talvez esse raciocínio possa ser tratado de maneira mais eficaz.

Espero que isto ajude.

As práticas que já vi são:

1. Qualquer pessoa pode criar ramificações de trabalho para o conteúdo de seus corações. Um desenvolvedor deve ser capaz de criar uma ramificação de recursos no segundo em que achar que há um ponto em armazenar seu trabalho atual em andamento. Como eles querem / devem fazer backup no final do dia, querem compartilhá-lo com outro membro da equipe, precisam ser protegidos contra alterações na principal ou o que seja.

2. Qualquer um pode fazer absolutamente qualquer coisa para desenvolver ramos. O desenvolvedor deve ser capaz de mesclar do main a partir do minuto em que outro desenvolvedor diz a eles que algo que eles precisam foi integrado no main.

3. Para mesclar para main (integração), existem três opções:

   • Os desenvolvedores fazem isso eles mesmos. Eles apenas discutem os riscos com o desenvolvedor líder e testam os recursos adequadamente. Isso implica que alguém tem as permissões; se alguém quebra as regras, é repreendido e a mudança errada é revertida.
   • Outro desenvolvedor faz isso depois de revisar as alterações. Ele ainda exige que todos tenham permissão para fazê-lo; as regras ainda são aplicadas pelo desenvolvedor principal.
   • Há um integrador designado que analisa e funde no principal. Mas o integrador faz parte da equipe e precisa entender o código. Em equipes menores, seria a mesma pessoa que arquiteto; em maiores, elas seriam separadas, mas precisariam cooperar estreitamente.

4. Quem prepara um recurso deve adaptar o script de construção. Mas não tenho certeza de como isso funciona com o TFS; nos sistemas que eu usei, o script de construção sempre foi apenas um arquivo com versão, então os desenvolvedores o editaram como qualquer outro e ele foi integrado com todo o resto.

5. Se houver um integrador designado, eles geralmente cuidam de definir (qual script executar) e iniciar as compilações. Caso contrário, o líder da equipe faz isso, o membro designado da equipe faz isso ou alguém tem permissões e o delegado lidera a configuração e o início de compilações específicas, caso a caso.

6. Em nenhum caso, as operações acima devem exigir um operador fora da equipe. O operador é necessário apenas para configurar as permissões, criando réplicas e coisas do tipo.

Não importa as "melhores práticas" (tenha paciência comigo), esse é um problema de gerenciamento - fundamentalmente, você não é capaz de fazer seu trabalho corretamente devido às restrições impostas a você.

Na verdade, não importa o que é a "melhor prática" - esse é um problema simples e demonstrável que afetará a produtividade de você e sua equipe e você precisará assumi-lo com o gerenciamento de linha nessa base.

Percebo que brandir um documento de práticas recomendadas pode (mas apenas pode ) ajudar na tentativa de convencê-los, mas é muito melhor a noção de que você terá que ter membros da equipe de desenvolvedores sentados em suas mãos enquanto esperam por alguém em um fuso horário diferente para agirem juntos, a menos que os processos sejam aprimorados / racionalizados.

E não seja muito confuso - por mais que você queira saber por que as restrições estão em vigor, qual é a justificativa ...