Relatório livre ESG: gerenciamento de dados sem emenda com Avere FXT
Entrega contínua é definida como um processo no qual as equipes de desenvolvimento de software se concentrar em implantação e refinamento acima de qualquer imperativo para trabalhar em novos recursos.
Como uma disciplina técnica isso é bom em princípio, especialmente se soubermos para onde queremos ir com o projeto na mão.
Mas a navegação e unidade para a entrega contínua precisa de algum tipo de auto-GPS ou mecanismo de direção para manter as rodas alinhadas.
Se a entrega contínua vê código de avanço de desenvolvedores em um serviço de controle de versões, então precisamos de uma ferramenta de gestão para dirigir-nos desde o início. Nosso mecanismo de direção e motor controles aqui vêm de uma mudança e um sistema de gerenciamento de configuração, sem o qual pode ser gasto de energia para nada.
O espírito de equipe
Desenvolvedores de aplicativos de software, e também os membros não-técnicos da equipe, precisa ser capaz de analisar seu fluxo de trabalho constantemente. Se isso soa um pouco lanoso, queremos dizer que é preciso ser capaz de controlar o que as mudanças de software estão sendo mainlined no motor de produção a qualquer momento.
Este controle vai nos permitir mesclar as alterações no fluxo de produção sem o projeto saindo dos trilhos. Pense nisso como um motorista de carro que querem realizar uma mudança de marcha da segunda para a terceira e não uma mudança de bloco de segunda a quarta, ou pior ainda uma estocada da segunda para a quinta marcha que poderia resultar em uma perda total de momentum.
Fica mais complicado quando percebemos que há mais de uma pessoa ao volante e tudo que eles precisam estar lendo o mesmo roteiro. Tanto o desenvolvimento e as funções de operações terá ampla divulgação de todas as informações do projeto e deve ser capaz de acessá-lo a partir de um sistema comum.
A importância deste ficará mais claro quando passamos desenvolvimento passado e em testes de aceitação do usuário e de produção full-blown.
Quociente de inteligência
É realmente difícil de fazer a entrega contínua, sem um bom sistema de gerenciamento de configuração. Isso ocorre porque a equipe de programação precisa automatizar construir, testar e implementar ferramentas e scripts várias vezes. Eles também precisam sincronizar lançamentos e saber como fazer um rollback se necessário.
Essas pessoas vão precisar de experiência em várias ferramentas de software, que exige uma profunda camada de gerenciamento de código inteligente de existir em algum nível ou outro.
Ok, na justiça, esta é mais uma tarefa para a unidade de DevOps do que para uma unidade incorporadora pura, mas os programadores ainda poderá ter de criar a documentação, processos ou scripts para permitir rollback e afins.
O desafio é ser capaz de auditar um sistema para mostrar o que estava ao vivo em qualquer ponto. Também vamos ter que verificar e ver se nosso sistema de gerenciamento de conteúdo pode lidar com todos os diferentes tipos de ativos envolvidos - e não apenas o código-fonte, mas também imagens, vídeos, binários, bases de dados e assim por diante.
Então, onde é que vamos virar? Temos marca comercialmente sistemas de controle de versão e ferramentas de repositório e temos alternativas open-source.
Com Git de pé como um serviço de controle de versão de pleno direito de escolha para muitos usuários, certamente este é todo o conjunto de ferramentas que precisamos? Bem, sim e não.
Git é forte, mas tem pontos fracos em áreas como a refatoração de código Java. É granular e poderoso em testes de verificação, mas mais lento quando se trabalha com vários tipos de arquivos, como arquivos binários, onde poderíamos argumentar que a equipe tem menos controle.
Mas Git manteve-se muito popular (que é um dos bebês de Linus Torvald, afinal de contas) e teve muitos defensores, apesar de seus bolsos de funcionalidade ocasionalmente limitado ou parcialmente contestada.
Aprenda a amar Git
É por isso que temos visto as maiores marcas em gerenciamento de versão distribuído alinhar para se encaixar com Git.
Talvez alguns destes movimentos foram tomadas em parte para defender a nossa sugestão de que o coração de entrega contínua encontra-se em gerenciamento de configuração. Vamos cavar mais fundo.
No ano passado Perforce construído Git Fusão para estender suas capacidades de gestão versão da empresa para repositórios Git. Neste cenário, os desenvolvedores de software atualmente usando Git pode continuar a usar as suas capacidades Git preferenciais, mas agora também se apossar de novas ferramentas para a personalização, a reutilização eo compartilhamento de projetos.
A proposição de tecnologia aqui é que os usuários Perforce e usuários do Git deve ser capaz de utilizar as ferramentas e os métodos de sua escolha, mas ainda mantêm uma "fonte única de verdade" e, fundamentalmente, de uma única interface para o sistema de controle de revisão central. Isto poderia ser GIT ou forçosamente, dependendo das preferências.
Director de Marketing Europeu na Perforce Mark Warren, diz que, se você quiser ter mais de um sistema de controle de versão de trabalho em conjunto que é bom, mas é prudente escolher dois que tiveram seu DNA fundido.
Eles deveriam pelo menos ter alinhado os seus roteiros ou parceria de modo que você pode acabar com um sistema de registro - ou, mais precisamente ainda, registro de um único sistema de (código de software).
Estes são os blocos de construção essenciais para a entrega contínua de existir em um backbone de gerenciamento de configuração. Indo mais longe, quando Warren fala sobre configuração e controle de versão de código de software, ele prefere o conceito de "versão de tudo."
Sob esse conceito guarda-chuva (ou doutrina versão) que poderia ser a versão controlar todo o caminho de volta para o código fonte do kernel. Melhor ainda, poderíamos estar controlando versão (ou versionamento se preferir) a volta por cima no nível da arquitetura de modelagem e aplicação.
"A arquitetura de uma aplicação moderna tem blocos de código, scripts, componentes e informações de configuração de todo o caminho através dele. Mas há também notas, anotações, documentação complacência e talvez até tutoriais em forma de vídeo que compõem o total de imóveis de aplicação ", diz Warren.
"Nós quase necessidade de redefinir as partes constituintes de uma aplicação e alimentação de todos estes elementos em nosso sistema de controle de revisão, se queremos permanecer na pista."
Mind the gap ar
Enquanto as equipes de desenvolvimento de software agora trabalhar para empurrar para fora múltiplas variantes de uma aplicação em diferentes plataformas, esses fatores de controle tornam-se ainda mais importante.
Em um mundo ideal, a entrega contínua começa a tornar-se enraizado nas funções essenciais da equipe de DevOps para que seja simbioticamente consumidos pelas funções de automação e feedback que esses caras viver.
Então, é uma "automatizar tudo" mantra é uma boa idéia quando se trata de mudar e de gerenciamento de configuração?
Sim, principalmente, mas não é absolutamente sempre, de acordo com Warren. "Pode haver a 10 por cento do fator humano na prestação contínua e gestão de mudanças em áreas do setor, como a defesa", diz ele.
"Pode ser que exista uma" folga "entre desenvolvedores e operações de trabalho em conjunto, por exemplo, um disquete é feita através do corredor de uma área para outra, para instalar os dados sensíveis. Aqui torna-se mais um caso de automatizar quase tudo ".
Nós engavetar a mudança e apresentá-lo no momento adequado
O processo de implantação também podem requerer revisão por pares - uma parte inerente do processo. Ferramentas existem no quadro da Perforce para que desenvolvedores possam parar e pedir a revisão a qualquer momento.
Mas quando dizemos que parar não queremos dizer que precisamos parar o aplicativo em execução. Nós engavetar a mudança, aumento, correções de bugs, novo recurso ou a introdução de uma nova peça de documentação e apresentá-lo no momento adequado.
Lembre-se do hardware
Estas técnicas funcionam melhor para software e quando há um monte de automação e testes. Onde hardware bem como software está sendo construído, há também um ponto de jump-off em que você precisa parar e fazer um protótipo. Uma vez que os protótipos são caros, nós queremos ser capazes de escolher um ponto em que podemos executar esta ação eficaz.
Nós tê-lo convencido ainda de que o coração de mentira contínua entrega em gerenciamento de configuração, ou mudança e gerenciamento de configuração para ser mais exato?
Tem que ser assim porque a entrega contínua, sem controle de revisão é como beber de uma mangueira de incêndio, voando às cegas ou qualquer outra coisa que implica uma sobrecarga totalmente equivocada do poder, sem claro ponto final estratégico.
Tente entrega contínua, sem controle de versão, se quiser, mas como uma questão de boas práticas e de bom senso, sugerimos que você não tentar reinventar a roda. ®
via Alimentar (Feed)
Nenhum comentário:
Postar um comentário