quinta-feira, 5 de setembro de 2013

Entrega contínua: O que funciona (eo que não)


Ganhe um topo de gama HP Spectre laptop


A noção de que poderia muito bem automatizar tudo o que é comum no mundo perpetuamente dinâmica de entrega contínua.


O que contínua (desenvolvimento de software aplicativo) A entrega efectiva implica e é uma solução prática o tempo todo?







Trata-se efetivamente como o reabastecimento de seu carro durante a condução. Ou talvez uma analogia melhor seria uma linha de montagem da fábrica que produz bolos de creme. Embora as novas matérias-primas são bombeados para funis e tanques de alimentação do processo de fabrico, a linha de montagem impede de se mudar para produzir mais bolos.


Tudo é contínua a menos que controle ou gestão da qualidade decide parar a linha de produção por causa de erros, produtos sub-padrão ou em manutenção.


Let them eat cake


É o mesmo para software como para bolos de creme: a linha de montagem (a equipe de programação) trabalha constantemente para alimentar matérias-primas (sangue, suor e código) para a planta de produção (sistema de controle de revisão) para que a mistura de bolo (fases de integração automatizados ) pode manter a produção de novo produto final.


Bolo de degustação por lote (análise estática) é acompanhado por controle de qualidade de nível superior (teste de unidade) eo produto acabado é entregue para a loja de bolo (a pré-produção ou ambiente de produção) de forma contínua.


Isso tudo funciona bem, em princípio, a menos que o consumidor realmente queria sanduíches de bacon, em primeiro lugar.


É ainda pior se o consumidor tem uma alergia ao glúten que impede comer bolos de qualquer maneira. Em outras palavras, o utilizador é mais importante do que o processo, no entanto, é eficiente.


Mesmo que aceitemos tudo o que precede, os processos que ainda deve ser manual e por quê? Além disso, como é que vamos reduzir os riscos durante todo o ciclo de vida de um projeto de fornecimento contínuo?


Websecurify , uma empresa de análise de vulnerabilidade, explica que durante as fases de teste de um projeto de entrega contínua, devemos ver os testes de segurança automatizados pedágios empregada para identificar vulnerabilidades.


"Se uma vulnerabilidade crítica é identificada, o processo é interrompido e feedback entregue à equipe de desenvolvimento. O gasoduto não pode completar antes as questões críticas são remediados, garantindo assim uma melhor segurança ", diz a empresa.


Websecurify mais detalhes a diferença entre testes de segurança automatizados de entrega estático (caixa-branca) contínua que trabalha no código fonte da aplicação, ao contrário de dinâmicas (caixa-preta) analisadores que realizam testes em tempo real simulando um ataque real.


Ataques de segurança não é o único risco de entrega contínua e vulnerabilidade: precisamos examinar robustez aplicação e realizar procedimentos de depuração estritas da frente para trás. Mas a segurança pure-play não é um mau lugar para começar.


Então, é a entrega contínua sempre um erro? Por que manter empurrando lançamentos em produção, se o software não é eficaz e eficiente aos olhos dos usuários?


Muito, muito jovem


Existe um risco de muito, muito rápido para os clientes - e não deve usuários estar no comando de qualquer maneira?


ThoughtWorks cientista-chefe Martin Fowler comentou que um estado de entrega contínua é experiente quando o time software prioriza a necessidade de manter o software destacável e acima trabalhando em novos recursos.


Este é um estado onde as implantações de botão de qualquer versão do projeto de software pode ser canalizada para qualquer ambiente (ou plataforma) de forma on-demand. Isso vai de alguma forma para colocar os usuários no comando, mas não toda a maneira, por qualquer meio.


Fowler e sua equipe nos lembrar que em um período de atividade de programação, a entrega contínua (um termo cunhado por ThoughtWorks) se resume a um processo de construção de executáveis ​​e executar testes automatizados sobre os executáveis ​​para detectar problemas.


A partir desse ponto, podemos empurrar os executáveis ​​em produção (ou pelo menos a pré-produção ou produção-like) ambientes como eles começam a trabalhar. A teoria é que isso permite que a equipa para construir extensões incrementais para a maneira como o software funciona na base de que os utilizadores pediram em primeiro lugar.


Conectar os usuários de volta para a cadeia de fornecimento contínuo através de um processo de coleta de requisitos diligente é a chave para ter certeza que não é um caso de muito, muito rápido para os clientes.


Isto é, quando o Nirvana entrega contínua é alcançada: não é apenas uma questão de entrega contínua, mas também uma análise de requisitos contínua e satisfação do usuário. Este Nirvana em particular não é facilmente adquirida sem esforço meditativo concentrado.


Como contínua entrega prática piloto na Europa na ThoughtWorks, Kief Morris ecoa esse sentimento.


"Os lugares mais importantes a ter etapas manuais no processo de entrega estão revendo feedback e dados sobre como as pessoas estão usando o software, decidindo o que muda para implementar e implementar as mudanças", diz ele.


"O objetivo da automação na entrega contínua é permitir que a equipe a centrar a sua atenção sobre o que construir, em vez de gastar seu tempo empurrando os bits em servidores."







via Alimentar (Feed)

Nenhum comentário:

Postar um comentário