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

10

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.

Michael Chatfield
fonte
WHO should be performing said branching/merging.é uma decisão organizacional interna. Não é realmente algo que poderia ajudá-lo com ...
yannis
2
Importa-se de nos contar os motivos alegados dados para um procedimento tão bizantino? Meu palpite é "conformidade com o CMM nível N" ou "Sarbanes Oxley".
precisa
SOX, mas apenas em parte. Quando fomos ao TFS, os desenvolvedores tinham acesso ao Main e Dev. Mas então "alguns" desenvolvedores (nenhum na minha equipe) decidiram apenas fazer o trabalho de desenvolvimento no Main em vez de em um ramo do Dev, então agora todas as equipes estão sendo punidas.
Michael Chatfield

Respostas:

8

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.

Wyatt Barnett
fonte
3
+1, eu estava digitando algo semelhante: documente o tempo e o esforço perdidos: permita que os tomadores de decisão façam uma escolha informada: o risco de tudo o que eles estão tentando evitar com a política restritiva atual vale o custo?
Jamie F
Eu pretendo ter essa reunião, mas ajudaria se eu pudesse mostrar que essa política é contrária às "melhores práticas" do setor.
Michael Chatfield
Peguei vocês. Não tenho certeza se algo específico está lá, mas os bits no controle de origem no The Pragmatic Programmer podem ter algumas pedras preciosas neles. Pelo que parece, foi uma reação exagerada a alguns desenvolvedores ruins, em vez de uma decisão política pensada ou alguma política. Eu aceitaria um acordo em que a Ops possua se funde na Main. Eu também pressionaria para tornar as operações responsáveis ​​por garantir que a mesclagem não quebrasse nada, o que provavelmente acabará com eles saindo da empresa. . .
Wyatt Barnett
Segundo Jamie, todo o tempo gasto na fusão ou na espera de uma fusão deve ser registrado para que você tenha evidências. Não existe uma "melhor prática" que se adapte a todas as empresas. Trabalhei em grandes empresas, onde essa tarefa foi realizada por uma equipe dedicada de gerenciamento de configurações. Na minha empresa atual, há uma equipe dedicada de gerenciamento de release que não realiza o trabalho físico de mesclar para main, mas eles são o proprietário lógico e a auditam. Mas o IMHO ops geralmente não é o que toca o código fonte.
softveda
2

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.

Jan Hudec
fonte
Eu seria a favor de um "integrador designado", desde que seja realmente um desenvolvedor da equipe. Essa é a rota que eu espero de qualquer maneira; é uma equipe pequena (4 pessoas, incluindo eu). Espero que eu também tenha acesso para criar / executar os scripts do MS Build, será tolo criar scripts nAnt para implantações de desenvolvimento e, em seguida, que a equipe "ops" crie essencialmente o mesmo script para o MSBuild. Mas é o que farei se for necessário.
Michael Chatfield
2

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 ...

Murph
fonte
11
Sim, tentando muito não ser confrontador ... vindo de um cara que a esposa comprou para ele uma camiseta "Eu concordo com você, mas então nós dois estaríamos errados". :)
Michael Chatfield
Seu um assassino absoluta Quando você está bem (-: E, neste caso, é difícil argumentar que você não é ... mas você precisa de seu gerenciamento de linha no lado se anythings vai mudar
Murph