Bom fluxo de trabalho para desenvolvimento de software com scrum e integração contínua

Estou estudando uma abordagem para entender melhor como o fluxo de trabalho de integração contínua se encaixa melhor em uma empresa de desenvolvimento de software com o método scrum.

Estou pensando em algo assim:

Seria um bom fluxo de trabalho?

Você está lá, mas eu expandiria seu diagrama um pouco:

Basicamente (se o seu controle de versão permitir, por exemplo, se você estiver no hg / git), você deseja que cada par desenvolvedor / desenvolvedor tenha seu próprio ramo "pessoal", que contém uma única história de usuário na qual eles estão trabalhando. Quando eles concluem o recurso, precisam enviar para uma ramificação central, a ramificação "Release". Nesse ponto, você deseja que o desenvolvedor obtenha um novo ramo, para a próxima coisa em que ele precisa trabalhar. O ramo do recurso original deve ser deixado como está, para que quaisquer alterações que precisem ser feitas possam ser feitas isoladamente (isso nem sempre é aplicável, mas é um bom ponto de partida). Antes de um desenvolvedor retornar ao trabalho em um ramo de recurso antigo, você deve acessar o ramo de lançamento mais recente, para evitar problemas estranhos de mesclagem.

Neste ponto, temos um possível candidato a lançamento na forma do ramo "Release" e estamos prontos para executar nosso processo de IC (nesse ramo, obviamente, você pode fazer isso em cada ramo do desenvolvedor, mas isso é bastante raro em equipes de desenvolvedores maiores, pois desordena o servidor de IC). Esse pode ser um processo constante (esse é o ideal, o IC deve ser executado sempre que a ramificação "Release" for alterada) ou pode ser noturno.

Nesse ponto, você desejará executar uma compilação e obter um artefato de compilação viável no servidor de IC (ou seja, algo que você possa implementar de maneira viável). Você pode pular esta etapa se estiver usando um idioma dinâmico! Depois de criado, convém executar seus testes de unidade, pois eles são a base de todos os testes automatizados no sistema; é provável que sejam rápidos (o que é bom, pois todo o objetivo do IC é reduzir o ciclo de feedback entre desenvolvimento e teste) e é improvável que precisem de uma implantação. Se eles forem aprovados, você desejará implantar automaticamente seu aplicativo em um servidor de teste (se possível) e executar os testes de integração disponíveis. Os testes de integração podem ser testes automatizados de interface do usuário, testes BDD ou testes de integração padrão usando uma estrutura de teste de unidade (ou seja, "unidade"

Nesse ponto, você deve ter uma indicação bastante abrangente sobre se a compilação é viável. A etapa final que eu normalmente configuraria com uma ramificação "Release" é implantar automaticamente o candidato a liberação em um servidor de teste, para que o departamento de controle de qualidade possa fazer testes manuais de fumaça (isso geralmente é feito à noite, em vez de por check-in, como para evitar estragar um ciclo de teste). Isso apenas fornece uma rápida indicação humana sobre se a compilação é realmente adequada para uma versão ao vivo, já que é bastante fácil perder algumas coisas se o seu pacote de teste é menos abrangente e, mesmo com 100% de cobertura de teste, é fácil perder algo que você pode (não deveria) testar automaticamente (como uma imagem desalinhada ou um erro de ortografia).

Essa é realmente uma combinação de integração contínua e implantação contínua, mas, como o foco no Agile é a codificação enxuta e o teste automatizado como um processo de primeira classe, você deseja obter uma abordagem o mais abrangente possível.

O processo que descrevi é um cenário ideal, há muitas razões pelas quais você pode abandonar partes dele (por exemplo, ramificações de desenvolvedor simplesmente não são viáveis ​​no SVN), mas você deseja buscar o máximo possível .

Quanto à forma como o ciclo de sprint do Scrum se encaixa nisso, o ideal é que seus lançamentos ocorram o mais rápido possível e não os deixe até o final do sprint, para obter um feedback rápido sobre se um recurso (e compila como um todo) ) é viável, pois a mudança para a produção é uma técnica essencial para encurtar seu ciclo de feedback para o Dono do produto.

Conceitualmente sim. Um diagrama não está capturando muitos pontos importantes, como:

1. teste de unidade
2. confirmações incrementais
3. a preparação é implantada frequentemente, a produção geralmente não.

Você pode desenhar um sistema mais amplo para o diagrama. Eu consideraria adicionar os seguintes elementos:

Mostre suas entradas para o sistema, que são alimentadas aos desenvolvedores. Chame-os de requisitos, correções de bugs, histórias ou qualquer outra coisa. Mas atualmente o seu fluxo de trabalho assume que o visualizador sabe como essas entradas são inseridas.

Mostre os pontos de controle ao longo do fluxo de trabalho. Quem / o que decide quando uma alteração é permitida no trunk / main / release-branch / etc ...? Quais códigos / projetos são construídos no CIS? Existe um ponto de verificação para ver se a construção foi quebrada? Quem libera do CIS para preparação / produção?

Em relação aos pontos de controle, está identificando qual é a sua metodologia de ramificação e como ela se encaixa nesse fluxo de trabalho.

Existe uma equipe de teste? Quando eles estão envolvidos ou são notificados? Há testes automatizados sendo realizados no CIS? Como as quebras são devolvidas ao sistema?

Considere como você mapeará esse fluxo de trabalho para um fluxograma tradicional com pontos de decisão e entradas. Você capturou todos os pontos de contato de alto nível necessários para descrever adequadamente seu fluxo de trabalho?

Acho que sua pergunta original está tentando fazer uma comparação, mas não tenho certeza de quais aspectos você está tentando comparar. A Integração Contínua possui pontos de decisão como outros modelos SDLC, mas eles podem estar em diferentes pontos do processo.

Eu uso o termo "Automação de Desenvolvimento" para abranger todas as atividades automatizadas de criação, geração de documentação, teste, medição de desempenho e implantação.

Um "servidor de automação de desenvolvimento" possui, portanto, uma remessa semelhante, mas um pouco mais ampla, do que um servidor de integração contínua.

Prefiro usar scripts de automação de desenvolvimento conduzidos por ganchos pós-confirmação que permitem que as ramificações particulares e o tronco de desenvolvimento central sejam automatizados, sem exigir configuração adicional no servidor de IC. (Isso exclui o uso da maioria das GUIs de servidor de CI prontas para uso que eu conheço).

O script pós-confirmação determina quais atividades de automação executar com base no conteúdo da própria ramificação; lendo um arquivo de configuração pós-confirmação em um local fixo na ramificação ou detectando uma palavra específica (eu uso / auto /) como um componente do caminho para a ramificação no repositório (com Svn)).

(É mais fácil configurar com Svn do que Hg).

Essa abordagem permite que a equipe de desenvolvimento seja mais flexível sobre como eles organizam seu fluxo de trabalho, permitindo que a CI suporte o desenvolvimento em filiais com sobrecarga administrativa mínima (quase zero).

Existe uma boa série de posts sobre integração contínua no asp.net que você pode achar útil, que abrange bastante terreno e fluxos de trabalho que se encaixam com o que parece que você está fazendo depois.

Seu diagrama não menciona o trabalho realizado pelo servidor de IC (teste de unidade, cobertura de código e outras métricas, teste de integração ou compilações noturnas), mas presumo que tudo isso seja coberto no estágio "Servidor de integração contínua". Não sei ao certo por que a caixa de CI retornaria ao repositório central? Obviamente, ele precisa obter o código, mas por que precisaria enviá-lo de volta?

O CI é uma daquelas práticas recomendadas por várias disciplinas, não é exclusivo do scrum (ou XP), mas, na verdade, eu diria que seus benefícios estão disponíveis para qualquer fluxo, mesmo os não-ágeis, como a cascata (talvez úmida?) . Para mim, os principais benefícios são o ciclo de feedback apertado, você sabe rapidamente se o código que acabou de confirmar funciona com o restante da base de códigos. Se você estiver trabalhando em sprints e tendo seus stand-ups diários, poder consultar o status ou as métricas das últimas noites construídas no servidor de CI é definitivamente uma vantagem e ajuda a focar as pessoas. Se o proprietário do produto puder ver o status da compilação - um grande monitor em uma área compartilhada mostrando o status de seus projetos de compilação -, você realmente reforçou esse ciclo de feedback. Se sua equipe de desenvolvimento está comprometendo com frequência (mais de uma vez por dia e, idealmente, mais de uma vez por hora), as chances de você encontrar um problema de integração que leva muito tempo para resolver são reduzidas, mas se o fizerem, é claro que tudo e você pode tomar as medidas necessárias, todos parando para lidar com a versão quebrada, por exemplo. Na prática, você provavelmente não terá muitas compilações com falha que levam mais de alguns minutos para descobrir se está se integrando com frequência.

Dependendo dos seus recursos / rede, você pode considerar adicionar diferentes servidores finais. Temos uma compilação de IC que é acionada por uma confirmação no repositório e, assumindo que ela cria e passa em todos os testes, ela é implantada no servidor de desenvolvimento para que os desenvolvedores possam garantir que ele seja executado corretamente (você pode incluir selênio ou outros testes de interface do usuário aqui? ) Porém, nem toda confirmação é uma compilação estável; portanto, para acionar uma compilação no servidor de temporariedade, precisamos marcar a revisão (usamos mercurial) que queremos que sejam construídas e implantadas. Novamente, tudo isso é automatizado e acionado simplesmente com a confirmação de um determinado tag. Ir à produção é um processo manual; você pode deixá-lo tão simples quanto forçar uma compilação. O truque é saber qual revisão / compilação você deseja usar, mas se você marcar a revisão adequadamente, o servidor de IC poderá fazer o checkout da versão correta e fazer o que for necessário. Você pode estar usando o MS Deploy para sincronizar as alterações no (s) servidor (es) de produção ou empacotá-lo e colocar o zip em algum lugar pronto para um administrador implantar manualmente ... depende de como você está confortável com isso.

Além de subir uma versão, você também deve considerar como pode lidar com a falha e descer uma versão. Espero que isso não aconteça, mas pode haver alguma alteração nos servidores, o que significa que o que funciona no UAT não funciona na produção. Portanto, você libera sua versão aprovada e ela falha ... você sempre pode adotar a abordagem que identifica o bug, adicione algum código, confirme, teste, implante na produção para corrigi-lo ... ou você pode incluir alguns testes adicionais em torno do seu release automatizado para produção e, se ele falhar, será revertido automaticamente.

O CruiseControl.Net usa xml para configurar as compilações, o TeamCity usa assistentes. Se você deseja evitar especialistas em sua equipe, a complexidade das configurações de xml pode ser outra coisa a ter em mente.

Primeiro, uma ressalva: Scrum é uma metodologia bastante rigorosa. Eu trabalhei para algumas organizações que tentaram usar o Scrum, ou abordagens semelhantes ao Scrum, mas nenhuma delas realmente chegou perto de usar toda a disciplina. De minhas experiências, sou um entusiasta do Agile, mas um cético Scrum (relutante).

Pelo que entendi, Scrum e outros métodos Agile têm dois objetivos principais:

• O primeiro é fornecer um mecanismo explícito para gerenciar riscos e a descoberta contínua de riscos.
• O segundo é fornecer um mecanismo estruturado para comunicação com as partes interessadas, descoberta de requisitos e gerenciamento de requisitos.

O primeiro objetivo (gerenciamento de riscos) é alcançado através do desenvolvimento iterativo; cometendo erros e aprendendo lições rapidamente, permitindo que a equipe desenvolva o entendimento e a capacidade intelectual para reduzir riscos e avance para uma solução de risco reduzido com uma solução "austera" de baixo risco já na bolsa.

A automação de desenvolvimento, incluindo a integração contínua, é o fator mais crítico no sucesso dessa abordagem. A descoberta de riscos e o aprendizado da lição devem ser rápidos, livres de atritos e livres de fatores sociais confusos. (As pessoas aprendem MUITO mais rápido quando é uma máquina que diz que elas estão erradas, em vez de outra humana - os egos só atrapalham o aprendizado).

Como você provavelmente pode perceber - eu também sou fã de desenvolvimento orientado a testes. :-)

O segundo objetivo tem menos a ver com automação de desenvolvimento e mais com fatores humanos. É mais difícil de implementar, porque requer adesão do front-end da empresa, que dificilmente verá a necessidade da formalidade.

A Automação de Desenvolvimento pode ter um papel aqui, pois documentação e relatórios de progresso gerados automaticamente podem ser usados ​​para manter as partes interessadas fora da equipe de desenvolvimento continuamente atualizadas com o progresso, e radiadores de informações mostrando o status da construção e conjuntos de testes aprovados / reprovados podem ser usados ​​para comunicar o progresso no desenvolvimento de recursos, ajudando (espero) a apoiar a adoção do processo de comunicação Scrum.

Então, em resumo:

O diagrama que você usou para ilustrar sua pergunta captura apenas parte do processo. Se você quisesse estudar agile / scrum e IC, eu argumentaria que é importante considerar os aspectos sociais e humanos mais amplos do processo.

Devo terminar tocando o mesmo tambor que sempre faço. Se você está tentando implementar um processo ágil em um projeto do mundo real, o melhor indicador de sua chance de sucesso é o nível de automação implementado; reduz o atrito, aumenta a velocidade e abre o caminho para o sucesso.