Cuidando do seu sistema de integração contínua

Um dos meus papéis na minha equipe é a pessoa de construção . Sou responsável por manter / atualizar nossos scripts de construção e garantir que estamos construindo 'sem problemas' no servidor de integração contínua. Normalmente, não me importo com esse trabalho, embora muitas vezes pareça que estou constantemente cuidando do servidor de CI.

Às vezes, esse trabalho pode ser irritante porque, se a construção for interrompida, eu tenho que largar a história em que estou trabalhando e investigar a falha na construção. As falhas de compilação acontecem diariamente em nossa equipe. Às vezes, os desenvolvedores simplesmente não constroem localmente antes de confirmar, para que os testes falhem no servidor de IC. Nesta situação, eu gosto de chegar rapidamente à pessoa que teve o 'commit ruim', para que a compilação não fique quebrada por muito tempo. Às vezes (com muito menos frequência) existe uma condição estranha no servidor de IC que precisa ser depurada.

Sei que muitas equipes maduras usam a Integração Contínua, mas não há muito material disponível sobre boas práticas.

Meus problemas apontam que nossa integração contínua não é muito madura ou isso simplesmente faz parte do trabalho?

Quais são algumas boas práticas a serem seguidas? Quais são as características da integração contínua madura ?

Atualizar

Em vez de responder a alguns comentários, vou fazer uma atualização. Temos um comando único e simples que faz exatamente o que o servidor de compilação fará ao criar o aplicativo. Ele irá compilar, executar todas as unidades / integração e alguns testes rápidos baseados na interface do usuário.

Lendo as respostas de todos, parece que podemos ter dois grandes problemas.

1. Servidor de CI não está reclamando alto o suficiente quando uma compilação falha.
2. Os desenvolvedores não sentem que é responsabilidade de todos garantir que seu commit seja realizado com êxito.

O que torna as coisas mais difíceis na minha equipe é que temos uma equipe grande (10 ou mais desenvolvedores) E temos alguns membros da equipe offshore comprometendo-se quando nem estamos no trabalho. Como a equipe é grande e estabelecemos que pequenas e freqüentes confirmações são preferidas, às vezes temos muita atividade em um dia.

Em primeiro lugar: cada pessoa é responsável pelo processo de construção . Parece que os membros de sua equipe não são maduros ... Ninguém se importa em escrever código e enviá-lo para o servidor de IC, esperando que funcione. Antes de confirmar o código, ele deve ser testado na máquina local. Você deve ter certeza de que o código que você está verificando não interromperá a compilação. Obviamente, há casos em que a construção é interrompida involuntariamente (por exemplo, se um arquivo de configuração foi alterado ou se a consolidação incorreta foi feita inadvertidamente).

A maioria dos servidores de CI (usei apenas o Hudson) enviará um email automatizado detalhando as confirmações feitas que causaram a quebra da compilação. A única parte do seu papel é apoiá-los, parecendo duros até que o suspeito conserte o que eles quebraram.

Sua equipe errou uma coisa:

Ser responsável pelo servidor de construção não é o mesmo que ser responsável pela construção .

É de responsabilidade da pessoa que está fazendo o check-in do código fazê-lo "funcionar" (por algum valor do trabalho). O único motivo para ter um servidor de construção é capturar omissões nesse processo. Qualquer servidor de build que se preze pode notificar as pessoas que fizeram o check-in do código desde a última build (assim como qualquer pessoa interessada) com as seguintes informações:

• Construção quebrou!
• O que deu errado ao construir!
• O que mudou desde a última compilação!

Isso acontece com muita frequência por email. É importante que isso aconteça rapidamente após cada check-in.

A pessoa pode ver o que deu errado e corrigi-lo, e o servidor de construção notifica qualquer pessoa interessada que a construção está de volta ao normal. Isso deve acontecer por si só, sem o envolvimento de outras pessoas, exceto os responsáveis ​​pelo check-in.

Portanto, para responder à sua pergunta: Um ambiente de IC maduro NÃO exige o envolvimento de um zelador em sua operação normal.

Além disso, se "condições estranhas existirem" acontecerem com muita frequência, descubra o que a causa e torne o sistema mais robusto.

Mude o processo. Se uma confirmação interromper a construção, reverta automaticamente essa confirmação e notifique o desenvolvedor que a interrompeu. É tolice permitir que um erro de um membro da equipe desacelere o restante da equipe. Ou, em vez de ter as compilações de integração feitas automaticamente, peça aos desenvolvedores que verifiquem a máquina de integração e, se a compilação for bem-sucedida, eles poderão confirmar. Integração contínua não significa "faça o check-in de qualquer lixo que você goste e alguém o consertará".

A estratégia "ramo de ouro" não funciona, a menos que haja um porteiro para o ramo de ouro.

Um DVCS como o Git pode ajudar; em vez de confirmar, o desenvolvedor pode enviar apenas um conjunto de alterações para integração ao servidor de IC, e o servidor pode tentar integrar o conjunto de alterações. Se a integração for bem-sucedida, o conjunto de alterações será mesclado e, caso contrário, será rejeitado.

Um problema que vejo frequentemente é que os desenvolvedores não podem executar uma compilação local que possui exatamente as mesmas etapas que uma compilação de IC. Ou seja, o servidor de IC está configurado para incluir etapas extras, como testes de unidade / integração, cobertura etc. que não podem ser executadas localmente. Inevitavelmente, os desenvolvedores serão mordidos por uma das etapas que eles não podem executar localmente e começarão a questionar por que estão se preocupando em criar uma versão localmente antes do check-in.

Eu mantenho minha compilação inteira independente e o servidor de CI simplesmente inicia uma compilação de versão sem nenhuma configuração / etapas estranhas definidas. Os desenvolvedores podem executar uma versão compilada localmente antes do check-in, que inclui todas as etapas que serão executadas pela compilação do IC e ficar muito mais confiantes de que nada será interrompido ao fazer o check-in.

Os benefícios adicionais dessa abordagem incluem:

• é fácil alternar entre servidores de IC, porque você não investiu muito tempo configurando etapas estranhas
• todas as ferramentas em tempo de construção estão sob controle de origem, o que significa que todos os desenvolvedores estão usando exatamente o mesmo conjunto de ferramentas para criar seu sistema
• Além do ponto acima, é simples alterar as ferramentas de construção de maneira controlada

PS. todo o conceito de babá de construção é ridículo, mas outros já o abordaram.

Primeiro, os desenvolvedores não devem interromper as compilações regularmente - eles devem criar e executar os testes localmente antes de se comprometerem com a ramificação do IC. Deve ser uma marca de vergonha interromper a construção, e é importante fazer isso. Fiz isso através da publicação de estatísticas e vi outras equipes terem um "pacote de compilação", onde você coloca um dólar toda vez que quebra a compilação. No final do projeto, esse dinheiro vai para a cerveja.

Se a vergonha / orgulho pessoal não funcionar, você pode ter que mudar para coisas mais pesadas (por exemplo, ameaça de rescisão). Quebrar a construção antes de sair para o dia deve ser uma grande ofensa. E todo desenvolvedor deve ter uma notificação de status de compilação na área de trabalho. A melhor parte de tudo isso é que ele encoraja confirmações menores, que são preferidas de qualquer maneira.

Dito isto, a compilação às vezes será interrompida (razões de configuração do IC, por exemplo). E às vezes as pessoas estragam tudo e saem para o dia com a construção quebrada. É por isso que você deve procurar um processo que permita reversões rápidas e fáceis para boas versões conhecidas. Se você sempre pode reverter para a última versão boa (e ter a versão revertida implantada em todos os lugares necessários), no pior dos casos, uma versão quebrada em que o culpado deixou a noite, você pode rolar de volta à última versão boa e grite com ele de manhã.

Não posso recomendar o livro Entrega contínua o suficiente. Se você está procurando um guia sobre como amadurecer seu processo de IC, experimente.

Eu ouvi sobre uma coisa que a Microsoft (talvez?) Faz, que é ter o papel de criar babá se movimentar pela equipe. A maneira como eles fazem isso é que, quando alguém quebra a compilação (o que provavelmente deve incluir o check-in de algo que falha nos testes), ele assume a função. Isso torna as pessoas responsáveis ​​pelas conseqüências de suas ações de maneira muito direta. E, como é um trabalho um pouco chato, encoraja-os a não interromper a construção novamente.

A pessoa que é atualmente responsável pela construção pode ter um chapéu especial. Poderia haver uma cerimônia para entregá-lo.

Observe que, como diz Thorbjørn, ser responsável pela compilação não é o mesmo que ser responsável pelo servidor de compilação. A responsabilidade pelo servidor pode ficar permanentemente com um ou mais membros da equipe com infra-estrutura, enquanto a responsabilidade pela construção se move.

Agora, com detalhes do processo à parte, vou me juntar ao coro de pessoas que expressam consternação com os desenvolvedores que estão fazendo check-in sem ter executado uma compilação e teste. Inaceitável!

Se você tem alguns membros da equipe com maior probabilidade de quebrar a compilação (e com base em minha própria experiência, estou pensando principalmente nos membros de outro país), e se você estiver usando um bom controle de fonte moderno como o Mercurial ou Git, você pode fazer com que eles façam check-in em uma ramificação diferente para o restante da equipe, executem um processo de IC separado e mesclem automaticamente as alterações dessa ramificação para o tronco após uma compilação bem-sucedida (observe que você precisa execute uma segunda compilação e teste após a mesclagem antes de verificar a mesclagem!). Como a mesclagem automática nem sempre é bem-sucedida, isso eventualmente deixaria o ramo que requer atenção manual, o que poderia ser uma dor real. Pode ser menos doloroso do que ter código quebrado verificado para o resto da equipe.

Como Jonathan Khoo disse, todos vocês devem ser responsáveis ​​pelo servidor de compilação e pelo script de compilação. Existem três razões:

1. No momento, você tem um caso de "Barramento de 1", o que significa que, se você for atropelado por um barramento, todo o conhecimento do servidor de compilação e dos scripts de compilação será perdido.
2. Os scripts que foram escritos (com ou sem razão) por você tiveram apenas sua entrada. Assim como qualquer código, quanto mais pessoas envolvidas, mais ampla é a base de conhecimento que pode ser aplicada a ele.
3. Finalmente, quando algo dá errado, apenas você está sentindo a dor. A dor é uma coisa boa, mas não quando é isolada. No momento, você está lidando com a dor, mas se todos os outros estivessem com dor, você descobriria que eles acabariam sendo mais rigorosos no teste de código antes de cometer.

Estou muito envolvido com a CI e caio na armadilha de manter os scripts, mas aqui estão algumas coisas que você pode fazer para atenuar isso.

1. Os scripts de construção não devem ser executados apenas nos servidores de IC, mas também nas máquinas de desenvolvimento local. Eles devem produzir as mesmas saídas, executar os mesmos testes e falhar pelos mesmos motivos. Isso permite que os desenvolvedores executem o script antes de confirmar seu código.
2. Se alguém quebrar a compilação, torne-a pública através do uso de pop-ups da bandeja de tarefas, e-mails, luzes intermitentes, ruídos etc. Isso serve não apenas para embaraçar os membros da equipe, mas também para os demais membros da equipe. auxiliar.
3. Por um tempo, evite consertar a compilação. Peça a alguém para fazer isso. Se ninguém mais saltar, espere que coisas ruins aconteçam e use-o como um ponto de aprendizado para toda a equipe entender por que o servidor de IC é importante.
4. Tente manter o servidor de compilação e as máquinas de desenvolvimento livres de componentes de terceiros instalados, tanto quanto possível, principalmente mantenha o GAC limpo. Confie nos componentes de terceiros que estão na pasta da biblioteca de projetos. Isso ajuda a identificar componentes ausentes mais rapidamente.

A visibilidade irá ajudá-lo. Todos os membros da equipe precisam saber que há um problema ativo que eles devem corrigir. As notificações por email são úteis, mas se um desenvolvedor estiver ocupado e não reagir imediatamente, provavelmente o esquecerá e o email terminará em uma enorme pilha de notificações.

Você pode tentar usar ferramentas como Catlight ou BuildNotify . Eles mostram o status atual das construções importantes na área da bandeja. Toda vez que o desenvolvedor olhar para o relógio, verá que há uma versão quebrada que precisa ser corrigida.

O Catlight também mostrará quem quebrou a construção primeiro, pressionando socialmente essa pessoa, pois toda a equipe o verá em cada falha consecutiva na construção.

Uma estratégia é usar muitas ramificações pequenas para muitos projetos pequenos. Então, quando alguém quebra a construção, eles estão apenas quebrando a construção por si mesmos. Portanto, eles recebem o email irritado do servidor de compilação e cabe a eles se preocupar com isso.

Outra é melhorar o nível de responsabilidade das pessoas. Por exemplo, se você usar algo como o Rietveld , as pessoas não poderão se comprometer sem passar na revisão por pares. (Na prática, o processo é muito mais leve do que você pensa. Mas força as pessoas a "canalizarem" e trabalharem em várias coisas ao mesmo tempo.) Preservar a construção é de responsabilidade do responsável pela entrega e pelos revisores. Se alguém quebrar regularmente a compilação ou aprovar coisas que a quebram, não permita que eles dêem aprovações finais para confirmações. Combine com um processo em que qualquer pessoa pode reverter facilmente qualquer alteração, e a compilação não será interrompida com tanta frequência e não será interrompida assim que a alteração for feita.

Vou terminar com o refrão aqui e dizer que, na verdade, interromper a compilação ocasionalmente não é uma coisa tão ruim, pois mostra que o trabalho real está sendo feito. Sim, os desenvolvedores devem criar e testar antes de confirmar, mas o principal ônus do teste deve ser suportado pelas ferramentas de automação de desenvolvimento, incluindo o servidor de integração contínua. As ferramentas estão lá para serem usadas e, a menos que a construção seja interrompida de vez em quando, não está claro se você está se esforçando o máximo possível. No entanto, acho que a construção nunca deve permanecer interrompida por um período de tempo significativo e até favoreceria reversões automáticas ou um processo de confirmação em vários estágios, se isso ajudar a apoiar os objetivos duplos do feedback rápido de instalações de teste centralizadas e automatizadas, além de um tronco "verde".

Coisas para casais em mente:

1. Sua equipe precisa de um conjunto de padrões a seguir
2. Você precisa integrar o gerenciamento com a idéia de código limpo e se esforçar para aprimorar as práticas de código.
3. Teste teste teste! Sempre teste antes de fazer o check-in.
4. Embora eu concorde que não há problema em quebrar a compilação, isso é raro e eu digo uma ocasião extremamente rara que seria aceitável. Se isso for diário, eu estaria procurando a porta ou conversando com meu chefe sobre padrões.

No geral, vocês precisam estabelecer, redigir padrões com base nas melhores práticas e não nas suas práticas individualmente (obviamente, essas não estão funcionando). Quando todos concordarem com os padrões, inicie o processo de revisão de código e imponha os padrões. Parece que a gerência saiu de férias e nunca mais voltou. São coisas que honestamente são bastante básicas para qualquer loja. a base do bom código começa com bons padrões para ditar o código das equipes e como está escrito. Apenas meus pensamentos. Recentemente, entrei em uma situação semelhante no meu novo emprego e conversei com meu chefe. Explicou a ele que precisamos que o XYZ seja concluído porque isso afeta o ABC. Duas semanas depois, escrevi uma lista de padrões de código a seguir e a apresentei. Seguidos por meus colegas de trabalho, dando entrada e, cerca de 2 meses depois, tínhamos normas em vigor que resolviam toneladas de problemas.