Estratégia de controle de versão de software

O OSS Watch oferece orientação e orientação imparciais sobre o uso, desenvolvimento e licenciamento de software livre, software de código aberto e hardware de código aberto.
Se você quiser saber mais sobre qualquer um desses tópicos, somos as pessoas a quem perguntar.
home & gt; recursos & gt; notas informativas & gt; O que é controle de versão? Por que é importante para a devida diligência?
O que é controle de versão? Por que é importante para a devida diligência?
por Stuart Yeates em 1 de janeiro de 2005, última atualização em 9 de maio de 2013.
Introdução.
Um sistema de controle de versão (também conhecido como Revision Control System) é um repositório de arquivos, geralmente os arquivos do código-fonte dos programas de computador, com acesso monitorado. Todas as alterações feitas na origem são rastreadas, juntamente com quem fez a alteração, por que elas fizeram isso e referências a problemas corrigidos ou aprimoramentos introduzidos pela alteração.
Os sistemas de controle de versão são essenciais para qualquer forma de desenvolvimento distribuído e colaborativo. Seja a história de uma página wiki ou um grande projeto de desenvolvimento de software, a capacidade de rastrear cada alteração conforme foi feita e reverter as alterações quando necessário pode fazer toda a diferença entre um processo bem gerenciado e controlado e um descontrolado. , primeiro servido 'sistema. Ele também pode servir como um mecanismo de due diligence para projetos de software.
Acompanhamento de versões.
Os desenvolvedores podem querer comparar a versão atual de alguns softwares com a versão de ontem ou a versão do ano anterior. Como os sistemas de controle de versão acompanham todas as versões do software, isso se torna uma tarefa simples. Saber o que, quem e quando das mudanças ajudará a comparar o desempenho de determinadas versões, calcular quando os erros foram introduzidos (ou corrigidos) e assim por diante. Quaisquer problemas que surgirem de uma mudança podem ser seguidos por um exame de quem fez a mudança e as razões que eles deram para fazer a mudança.
Coordenação de Equipes.
O desenvolvimento de recursos é geralmente realizado por equipes, co-localizadas ou distribuídas. O controle de versão é fundamental para coordenar equipes de colaboradores. Ele permite que um colaborador trabalhe em uma cópia dos recursos e depois libera suas alterações de volta ao núcleo comum quando estiver pronto. Outros colaboradores trabalham em suas próprias cópias dos mesmos recursos ao mesmo tempo, sem serem afetados pelas alterações de cada um até que decidam mesclar ou confirmar suas alterações de volta ao projeto. Quaisquer conflitos que surjam - quando dois contribuintes mudam independentemente a mesma parte de um recurso - são automaticamente sinalizados quando as alterações são mescladas. Tais conflitos podem então ser gerenciados pelos contribuintes.
Normalmente, em projetos de software livre, os sistemas de controle de versão permitem que qualquer pessoa leia e copie os recursos do projeto, mas somente os usuários autenticados, conhecidos como committers, podem atualizar o código-fonte no repositório.
Diligência devida.
Muitas atividades nos negócios são acompanhadas por uma responsabilidade de realizar verificações de "due diligence". Precisamente o que esses testes implicam dependerá da atividade comercial em questão, mas, no que diz respeito à propriedade intelectual, uma importante atividade de "due diligence" é o rastreamento da propriedade de suas partes constituintes. Por exemplo, se alguém cria um software e deseja que sua organização o libere, sua organização quase certamente desejará verificar a proveniência de todo o código dentro do software. Esse processo é facilitado pela capacidade de rastrear quem fez as alterações no código e quando elas foram feitas. Um sistema de controle de versão permite que uma lista de colaboradores seja compilada e as datas de suas contribuições sejam verificadas. Essa lista pode ser facilmente checada com uma lista de contratos de IP.
O desenvolvimento aberto envolve colaboradores fazendo pequenas mudanças regulares nos recursos. Um sistema de controle de versão fornece um meio de monitorar essas mudanças à medida que elas ocorrem. Os sistemas automatizados notificarão os responsáveis ​​pelo gerenciamento do IP nas saídas do projeto. Essas notificações, juntamente com os logs fornecidos para cada modificação individual, permitem que os gerentes de projeto monitorem e rastreiem todas as contribuições.
O desenvolvimento aberto exige cuidado quanto à proveniência das contribuições. Projetos de desenvolvimento aberto precisam seguir as melhores práticas nesta área. Se ocorrer uma infração de IP, o sistema de controle de versão poderá ser usado para determinar a extensão da contaminação (quais arquivos foram afetados pela alteração problemática), quem realizou a alteração e quando a executou. Um sistema de controle de versão pode até mesmo ser usado para recuperar a última versão não contaminada do software.
Os sistemas de controle de versão também podem ser usados ​​para estabelecer precedência, quando há uma disputa em relação à propriedade do código ou das ideias.
O controle de versão tem sido estudado e entendido de perto na comunidade de engenharia de software há muito tempo. As soluções são estáveis, robustas e bem suportadas. Existem vários sistemas adequados para pequenas equipes locais e para grandes equipes distribuídas, tornando-as ideais para coordenar o desenvolvimento de software e para atenuar as diferenças de cultura e fuso horário.
O controle de versão é fornecido em sites como o Github, o SourceForge e o Google Code. Esses sites normalmente criam um conjunto de serviços relacionados ao controle de versão: arquivamento, downloads de lançamento, listas de discussão, rastreadores de bugs, hospedagem na Web e criação de farms. Essa faixa de funcionalidade os torna particularmente atraentes para os projetos que não possuem recursos para manter seu próprio servidor para controle de versão.
O CVS costumava ser o sistema de controle de versão de código aberto mais usado, mas atualmente o Subversion e o Git o ultrapassaram e são comumente usados ​​em projetos de código aberto. Os recursos básicos desses sistemas são muito semelhantes, mas oferecem funcionalidades diferentes de segurança, rede e abstração e licenças diferentes. Existem também muitas soluções proprietárias disponíveis em uma variedade de fornecedores.
Como discutido anteriormente, o controle de versão é uma ferramenta valiosa na manutenção de registros e na realização de análises para fins legais. Esses tópicos são discutidos em Desenvolvimento de software livre - Uma introdução à propriedade e problemas de licenciamento.

Estratégia de controle de versão de software
A empresa para a qual trabalho está começando a ter problemas com seu atual modelo de ramificação e fiquei me perguntando para quais diferentes tipos de estratégias de ramificação a comunidade foi exposta?
Há algum bom para situações diferentes? O que sua empresa usa? Quais são as vantagens e desvantagens deles?
fechado como não construtivo por casperOne Fev 24 '12 às 19:53.
No momento, esta questão não é adequada para o nosso formato de perguntas e respostas. Esperamos que as respostas sejam apoiadas por fatos, referências ou especialização, mas essa questão provavelmente solicitará debates, discussões, pesquisas ou discussões ampliadas. Se achar que esta questão pode ser melhorada e possivelmente reaberta, visite o centro de ajuda para obter orientação. Se essa questão puder ser reformulada para se ajustar às regras da Central de Ajuda, edite a pergunta.
17 respostas.
Aqui está o método que usei no passado com bom sucesso:
/ tronco - margem de sangramento. Próximo lançamento principal do código. Pode ou não pode trabalhar a qualquer momento.
/branches/1.0, 1.1, etc. Ramos de manutenção estáveis ​​do código. Usado para corrigir erros, estabilizar novos lançamentos. Se um ramo de manutenção, ele deve compilar (se for o caso) e estar pronto para QA / envio a qualquer momento. Se um ramo de estabilização, ele deve compilar e ter recursos completos. Nenhum novo recurso deve ser adicionado, nenhuma refatoração e nenhuma limpeza de código. Você pode adicionar um pré-prefixo para indicar ramos de estabilização vs ramos de manutenção.
/ branches / cool_feature. Usado para trabalhos altamente experimentais ou destrutivos que podem ou não entrar no tronco (ou um ramo de manutenção). Não há garantias de compilação de código, funcionamento ou comportamento normal. Deve durar o mínimo de tempo possível antes de se fundir na ramificação da linha principal.
/tags/1.0.1, 1.0.2, 1.1.3a, etc. Usado para marcar um pacote & amp; lançamento enviado. Nunca muda sempre. Faça quantas tags quiser, mas elas são imutáveis.
Eu recomendo fortemente ler a opinião de Eric Sink sobre o assunto:
Eu, como Eric, prefiro o estilo de "pasta" que ele fala.
Para o filão mãe sobre padrões de ramificação, veja Linhas Transplantadas de Brad Appleton: Padrões de Ramificação para Desenvolvimento de Software Paralelo. É pesado, mas não vi nada para superá-lo em termos de amplitude e profundidade de conhecimento sobre ramificação.
Nosso repositório se parece com:
/ trunk é o seu desenvolvimento padrão e de ponta. Usamos o CI para que isso sempre seja feito e aprovado nos testes.
/ branches é onde nós colocamos grandes mudanças 'sancionadas', ou seja, algo que sabemos que irá transformá-lo em tronco, mas pode precisar de algum trabalho e quebrar CI. Também onde trabalhamos em versões de manutenção, que possuem seus próprios projetos de CI.
/ sandbox cada desenvolvedor tem sua própria sandbox, além de uma sandbox compartilhada. Isso é para coisas como "Vamos adicionar um provedor LINQ ao nosso produto" tipo de tarefas que você faz quando você não está fazendo seu trabalho real. Pode eventualmente entrar no tronco, pode não ser, mas está lá e sob controle de versão. Não há CI aqui.
/ vendedor padrão do fornecedor para projetos nos quais compilamos, mas não é o código que mantemos.
/ ccnet são nossas tags de CI, somente o servidor de IC pode gravar aqui. A retrospectiva teria nos dito para renomear isso para algo mais genérico, como CI, BUILDS, etc.
Uma ramificação para o desenvolvimento ativo (/ main ou master, dependendo do jargão) Um branch para cada release de manutenção -> ele receberá apenas pequenas correções, enquanto todo o desenvolvimento principal vai para / main Um branch para cada nova tarefa: criar um novo ramo para trabalhar em cada nova entrada no seu Bugzilla / Jira / Rally. Comprometa-se frequentemente, documente a alteração usando check-ins de seixos em polegadas e mescle-os de volta à sua ramificação "pai" apenas quando ela estiver concluída e bem testada.
A primeira coisa: KISS (Mantenha isso simples, estúpido!)
* 1) Manter a manutenção da versão - por exemplo, Service Packs, correcções, correções de erros que podem ser fundidas para o trunk, se necessário e / ou necessário) * 2) major. minor. build. revision.
A pasta Tags não precisa ser registrada Apenas poucas codificações em ramificações de lançamento (simplifica a mesclagem) - sem limpeza de código, etc. Nunca codificar na pasta de tags Nunca coloque informações concretas de versão em arquivos de origem. Use Place-holders ou 0.0.0.0 que o mecanismo de compilação substituirá pelo número de versão que você está construindo Nunca coloque bibliotecas de terceiros em seu controle de origem (também ninguém adicionará bibliotecas STL, MFC etc. ao SVN ;-)) Apenas código de commit que compila Prefer usando variáveis ​​de ambiente ao invés de caminhos hard-coded (caminhos absolutos e relativos)
Nós nos ramificamos quando um lançamento está pronto para o controle de qualidade final. Se algum problema for descoberto durante o processo de controle de qualidade, os erros serão corrigidos na filial, validados e depois mesclados no tronco. Depois que o branch passa no controle de qualidade, nós o marcamos como um lançamento. Quaisquer hotfixes para essa versão também são feitos na ramificação, validados, mesclados ao tronco e, em seguida, marcados como uma release separada.
A estrutura da pasta seria semelhante a esta (1 linha de controle de qualidade, 2 lançamentos de hotfix e o tronco):
Usamos o estilo selvagem, selvagem e ocidental dos ramos-git. Temos algumas ramificações que têm nomes conhecidos definidos por convenção, mas, no nosso caso, as tags são realmente mais importantes para atender aos requisitos da política de processos corporativos.
Eu vi abaixo que você usa o Subversion, então estou pensando que você deveria verificar a seção sobre ramificação no Subversion Book. Especificamente, observe a seção "layout do repositório" em Manutenção de Filial e Padrões de Filiais Comuns.
A alternativa que não estou vendo aqui é uma filosofia de "Branch on Change".
Em vez de ter seu porta-malas, o "Oeste Selvagem", e se o porta-malas for o "Release Atual"? Isso funciona bem quando há apenas uma versão do aplicativo lançada por vez - como um site. Quando um novo recurso ou correção de bug é necessário, uma ramificação é feita para manter essa alteração. Geralmente, isso permite que as correções sejam migradas para serem liberadas individualmente e impede que os codificadores de caubóis adicionem acidentalmente um recurso que você não pretendia. (Muitas vezes é um backdoor - "Apenas para desenvolvimento / teste")
Os ponteiros de Ben Collins são bastante úteis para determinar qual estilo funcionaria bem para sua situação.
O Controle de Versão de Henrik Kniberg para Múltiplas Equipes Ágeis também tem alguns pontos positivos a serem levados em consideração.
Atualmente, temos uma filial para manutenção contínua, um ramo para "novas iniciativas", que significa apenas "coisas que sairão em algum momento no futuro; não temos certeza de quando". Ocasionalmente, também tivemos dois ramos de manutenção: um para fornecer correções para o que está atualmente em produção e outro que ainda está em QA.
A principal vantagem que vimos é a capacidade de reagir às solicitações e emergências do usuário mais rapidamente. Podemos fazer a correção no branch que está em produção e liberá-lo sem liberar nada extra que já tenha sido verificado.
A principal desvantagem é que acabamos fazendo muitas mesclagens entre filiais, o que aumenta a chance de que alguma coisa seja perdida ou mesclada incorretamente. Até agora, isso não tem sido um problema, mas é definitivamente algo para se ter em mente.
Antes de instituirmos esta política, geralmente fazíamos todo o desenvolvimento no tronco e apenas ramificávamos quando lançávamos o código. Em seguida, fizemos correções contra esse ramo, conforme necessário. Era mais simples, mas não tão flexível.
Jeff Atwood escreveu sobre isso em um bom post no blog; Esse post tem alguns links importantes nele.
Gnat escreveu esta excelente análise dos vários conselhos que você pode encontrar em estratégias de ramificação.
Não há uma estratégia de ramificação, é para isso que funciona:
O tamanho da sua equipe Seu produto e os períodos do ciclo de vida A tecnologia que você está usando (aplicativos da Web, incorporados e do Windows) Seu controle de origem, por exemplo, Git, TFS, Hg.
O post de Jeff Atwood divide várias possibilidades. Outro a acrescentar é o conceito de promoção (do link de Ryan Duffield). Nesta configuração você tem uma ramificação dev, testa bracnh e libera a ramificação. Você promove seu código até que ele atinja o ramo de lançamento e seja implantado.

Guias Beanstalk.
Índice.
Se você estiver interessado no controle de versão, mas ainda não o fez, o motivo mais comum que ouvimos é o quão confuso parece ser. O melhor lugar para começar se você é novo no controle de versão são os conceitos básicos.
Por que o controle de versão é importante?
Se você estiver lendo isso, é possível que você esteja atualizando documentos semelhantes a este: index-v12-old2.html. Vamos nos afastar disso e de fazer algo que não apenas permita que você controle seu código-fonte e arquivos, mas torne-se mais produtivo como uma equipe. Se isso soa familiar:
Comunique-se com sua equipe via e-mail sobre atualizações. Atualizações feitas diretamente no seu servidor de produção. Anexou acidentalmente alguns arquivos, que nunca podem ser recuperados novamente.
Agora você pode esperar por isso:
Nomes de arquivos e estruturas de diretório consistentes para todos os membros da equipe. Fazendo alterações com confiança e até mesmo revertendo quando necessário. Baseando-se no controle de origem como meio de comunicação para sua equipe. Implementando facilmente diferentes versões do seu código para servidores de preparação ou de produção. Entender quem fez uma mudança e quando aconteceu.
Os conceitos básicos
Acompanhamento de alterações.
Um sistema de controle de versão baseia-se principalmente em torno de um conceito, rastreando as alterações que ocorrem nos diretórios ou arquivos. Dependendo do sistema de controle de versão, isso pode variar de saber que um arquivo foi alterado para saber se caracteres específicos ou bytes em um arquivo foram alterados.
Na maioria dos casos, você especifica um diretório ou conjunto de arquivos que devem ter suas alterações controladas pelo controle de versão. Isso pode acontecer fazendo check-out (ou clonando) um repositório de um host, ou informando ao software qual dos seus arquivos você deseja ter sob controle de versão.
O conjunto de arquivos ou diretórios que estão sob controle de versão é mais comumente chamado de repositório.
Conforme você faz alterações, ele rastreia cada alteração nos bastidores. O processo será transparente para você até que você esteja pronto para confirmar essas alterações.
Comprometendo-se
Ao trabalhar com seus arquivos que estão sob controle de versão, cada alteração é rastreada automaticamente. Isso pode incluir modificar um arquivo, excluir um diretório, adicionar um novo arquivo, mover arquivos ou qualquer outra coisa que possa alterar o estado do arquivo. Em vez de registrar cada alteração individualmente, o sistema de controle de versão esperará que você envie suas alterações como uma única coleção de ações. No controle de versão, essa coleção de ações é conhecida como confirmação.
Revisões e Changesets.
Quando uma confirmação é feita, as alterações são registradas como um conjunto de alterações e recebem uma revisão exclusiva. Esta revisão pode ser na forma de um número incrementado (1, 2, 3) ou um hash exclusivo (como 846eee7d92415cfd3f8a936d9ba5c3ad345831e5) dependendo do sistema. Conhecendo a revisão de um conjunto de alterações, facilita a visualização ou referência posterior. Um changset incluirá uma referência para a pessoa que fez o commit, quando a mudança foi feita, os arquivos ou diretórios afetados, um comentário e até mesmo as mudanças que aconteceram dentro dos arquivos (linhas de código).
Quando se trata de colaboração, visualizar revisões passadas e conjuntos de alterações é uma ferramenta valiosa para ver como seu projeto evoluiu e para revisar o código dos colegas de equipe. Cada sistema de controle de versão possui uma maneira formatada de visualizar um histórico completo (ou log) de cada revisão e conjunto de alterações no repositório.
Obtendo atualizações.
Como membros de sua equipe confirmam alterações, é importante que você tenha a versão mais recente. Ter a última versão reduz a chance de um conflito. Obter as últimas alterações de um repositório é tão simples quanto fazer um pull ou atualizar de outro computador (geralmente um servidor hospedado ou centralizado). Quando uma atualização ou solicitação é solicitada, somente as alterações desde a última solicitação são baixadas.
E se a última atualização ou confirmação resultar em um conflito? Ou seja, e se suas alterações forem tão semelhantes às alterações feitas por outro membro da equipe que o sistema de controle de versão não pode determinar qual é a alteração correta e autoritativa? Na maioria dos casos, o sistema de controle de versão fornecerá uma maneira de visualizar a diferença entre as versões conflitantes, permitindo que você faça uma escolha. Você pode editar os arquivos manualmente para mesclar as opções ou permitir que uma revisão conquiste a outra. Você pode querer colaborar com a pessoa que fez o outro se comprometer para ter certeza de que você não está desfazendo seu trabalho importante!
Difundindo (ou visualizando as diferenças)
Como cada confirmação é registrada como uma alteração em um arquivo ou conjunto de arquivos e diretórios, às vezes é útil visualizar o que foi alterado entre as revisões. Por exemplo, se uma implantação recente do seu site for interrompida e você restringir a causa a um determinado arquivo, a melhor ação a tomar é ver o que foi alterado recentemente nesse arquivo. Ao visualizar um diff, você pode comparar dois arquivos ou até mesmo um conjunto de arquivos para ver quais linhas de código foram alteradas, quando foram alteradas e quem as alterou. A maioria das ferramentas de controle de versão permite comparar duas revisões sequenciais, mas também duas revisões de qualquer lugar no histórico.
Ramificação e fusão.
Existem alguns casos em que você quer experimentar ou confirmar alterações no repositório que podem quebrar as coisas em outro lugar no seu código (como trabalhar em um novo recurso). Em vez de confirmar esse código diretamente no conjunto principal de arquivos (geralmente chamado de tronco ou mestre), você pode criar algo chamado ramificação. Uma ramificação permite criar uma cópia (ou instantâneo) do repositório que você pode modificar em paralelo sem alterar o conjunto principal. Você pode continuar a enviar novas alterações para o ramo enquanto trabalha, enquanto outras se comprometem com o tronco ou mestre sem que as alterações afetem umas às outras.
Uma vez que você esteja confortável com o código experimental, você vai querer torná-lo parte do tronco ou master novamente. É aqui que entra a fusão. Como o sistema de controle de versão registrou todas as alterações até agora, ele sabe como cada arquivo foi alterado. Ao mesclar a ramificação com o tronco ou mestre (ou até mesmo outra ramificação), sua ferramenta de controle de versão tentará mesclar de forma transparente cada arquivo e linha de código automaticamente. Depois que uma ramificação é mesclada, ela atualiza o tronco ou o mestre com os arquivos mais recentes.
Por exemplo, digamos que você queira experimentar um novo layout para um site. Isso pode exigir grandes alterações em muitos arquivos, pode quebrar o código existente e pode não resultar como esperado. Também pode levar muito tempo, portanto, você deseja continuar confirmando as alterações. Em vez de se comprometer com o tronco ou com o conjunto principal de arquivos, você cria uma ramificação. Deste ponto em diante, quaisquer alterações feitas na nova ramificação não afetarão outras pessoas no tronco ou no mestre. Dias ou semanas podem passar, permitindo que você faça alterações, teste e refine. Quando o novo layout estiver funcionando corretamente e você estiver confortável com o resultado, provavelmente estará pronto para torná-lo parte permanente do site. Este é o ponto onde você irá mesclar o ramo com o tronco ou mestre. Quando a fusão for concluída, ela combinará as alterações da ramificação com a versão mais recente do tronco ou mestre.
Em alguns casos, o sistema de controle de versão pode não ser capaz de descobrir qual alteração aplicar entre duas revisões ao fazer uma mesclagem. Se isso acontecer, surgirá um conflito. Um conflito neste cenário é o mesmo que o conflito mencionado acima e requer intervenção manual para decidir quais arquivos ou linhas de código devem permanecer.
Tipos de sistemas de controle de versão.
Os três sistemas de controle de versão mais populares são divididos em duas categorias principais, centralizadas e descentralizadas (também conhecidas como distribuídas).
Controle de Versão Centralizado.
No momento desta publicação, o sistema de controle de versão mais popular é conhecido como Subversion, que é considerado um sistema de controle de versão centralizado. O conceito principal de um sistema centralizado é que ele funciona em um relacionamento de cliente e servidor. O repositório está localizado em um local e fornece acesso a muitos clientes. É muito semelhante ao FTP em que você tem um cliente FTP que se conecta a um servidor FTP. Todas as mudanças, usuários, commits e informações devem ser enviadas e recebidas deste repositório central.
Os principais benefícios do Subversion são:
Ao mesmo tempo, o Subversion tem algumas desvantagens:
Dependente do acesso ao servidor. Difícil de gerenciar um servidor e backups (bem, não com o Beanstalk, é claro!) Pode ser mais lento porque cada comando se conecta ao servidor. Ferramentas de ramificação e mesclagem são difíceis de usar.
Controle de Versão Distribuída.
Sistemas distribuídos são uma opção mais recente. No controle de versão distribuído, cada usuário tem sua própria cópia de todo o repositório, não apenas os arquivos, mas também o histórico. Pense nisso como uma rede de repositórios individuais. Em muitos casos, embora o modelo seja distribuído, serviços como o Beanstalk são usados ​​para simplificar os desafios técnicos de compartilhamento de alterações. Os dois sistemas de controle de versão distribuídos mais populares são o Git e o Mercurial.
Os principais benefícios do Git e do Mercurial são:
Rastreamento de alterações mais poderoso e detalhado, o que significa menos conflitos. Nenhum servidor necessário - todas as ações, exceto o compartilhamento de repositórios, são locais (com confirmação offline). Ramificar e mesclar é mais confiável e, portanto, usado com mais frequência. É rápido.
Ao mesmo tempo, o Git e o Mercurial têm algumas desvantagens:
Qual é a certa para você? Isso realmente depende de como você trabalha. Geralmente recomendamos o Subversion se você está apenas começando, não está confortável com a linha de comando ou não planeja fazer muitas ramificações e mesclagens. Caso contrário, nós encorajamos você a experimentar o Git ou o Mercurial e ver se você gosta dele. Com o Beanstalk, você está livre para ir e voltar conforme necessário sem alternar os hosts.
Chris Nagele é o fundador da Wildbit, da Filadélfia, PA.

Controle de Versão e Gerenciamento de Liberação.
Praticamente tudo o que você faz no desenvolvimento de software afetará o controle de versão e o gerenciamento de versões direta ou indiretamente.
Antes de mergulharmos no processo, há alguns detalhes logísticos que precisamos discutir. Se você já colocou isso em prática, então você pode passar com segurança para a parte de planejamento desta seção, mas se você não tiver essa base no lugar, você vai querer ter certeza e resolvê-lo primeiro porque sem estas duas peças, o resto do processo será praticamente impossível.
Se você quiser enviar um software de alta qualidade, precisará do controle de versão, também conhecido como controle de origem, associado ao gerenciamento de versões. Seja você um desenvolvedor solo ou uma equipe de milhares de pessoas, você não pode ter um bom processo sem usar o controle de origem e uma maneira confiável de liberar o código finalizado. O primeiro permite que você gerencie seu código, e este último ajuda a obter esse código onde ele precisa estar.
Essas duas ferramentas entrarão e sairão virtualmente de todos os aspectos da entrega de software daqui para frente. Embora a extensão total de cada um deles esteja fora do escopo dessas lições, reunimos uma breve visão geral para orientá-lo na direção certa.
Controle de versão.
Sua primeira escolha seria qual plataforma de controle de origem é ideal para você e sua equipe. Veja uma pequena lista de algumas das opções mais populares:
Embora o controle de origem esteja fora do escopo do que estamos discutindo, há alguns ótimos tutoriais disponíveis. O GitHub criou o Try Git, o Beanstalk tem uma variedade de guias para usar o Git, os criadores do Tower Learn Git, e o Joel Spolsky criou o Hg Init para ajudá-lo a começar a usar o Mercurial.
Depois de decidir sobre uma plataforma de controle de origem, você precisará de um local para armazenar seu código. Você pode optar por auto-hospedar seu controle de origem, mas há um punhado de aplicativos disponíveis para facilitar o processo, dependendo da plataforma escolhida. E se você é novo no controle de origem, sugiro usar um provedor hospedado para que você possa se concentrar no aprendizado da ferramenta em vez de gerenciá-la. Alguns dos provedores de controle de origem hospedados mais populares são:
Existem alguns benefícios de usar um provedor de controle de origem hospedado, mas o maior benefício é que eles geralmente são mais fáceis de se conectar a outras ferramentas. Como você descobrirá rapidamente, o controle de origem estará no centro do processo e, quanto mais fácil for conectá-lo a outras ferramentas, mais produtivo você será.
Gerenciamento de Liberação.
Durante todo o processo de desenvolvimento de software, seu código passará por ciclos de desenvolvimento, teste e correção. Dependendo da sua equipe, tecnologia, plataforma e outras variáveis, você provavelmente terá vários ambientes que você usa para gerenciar seu aplicativo. 1 Para testar e lançar softwares com eficiência, é necessário ter um processo de lançamento simples e confiável para colocar seu código nos vários ambientes.
Suas opções para gerenciamento de versões são literalmente infinitas. Você pode escrever seus próprios scripts totalmente a partir do zero ou usar ferramentas como Capistrano, Mina, Fabric ou dploy. É claro que essas são apenas a ponta do iceberg, mas é provável que exista uma ferramenta equivalente disponível para sua plataforma.
Flexibilidade & amp; Recuperação.
Seu processo de lançamento será o gargalo na sua capacidade de enviar software. Se for difícil liberar o código, você não lançará com tanta frequência e poderá acabar enfrentando escolhas difíceis nas quais precisa liberar uma atualização, mas tenha medo de interromper seus clientes ou agir rapidamente. Com um bom processo de lançamento, você deve estar incrivelmente confiante em liberar atualizações sem interrupção para seus clientes. A melhor regra para saber se o processo de lançamento é bom é se você fica ansioso ao liberar atualizações. Essa ansiedade é muitas vezes um sintoma de falta de confiança em seus processos, e você provavelmente deveria gastar algum tempo simplificando seus lançamentos.
Além do lado necessário de obter seu código onde ele precisa estar, um dos maiores benefícios do bom gerenciamento de lançamentos é a capacidade de reverter no caso de uma emergência. Não importa o quanto seu processo de desenvolvimento e lançamento seja aprimorado, você ocasionalmente terá soluços em produção. Quando isso acontecer, convém reverter facilmente para sua base de códigos lançada anteriormente sem quebrar nada. Dessa forma, você não é forçado a apressar uma consertar mal a porta. Em vez disso, você só reverte para resolver o problema sem afetar os clientes e, em seguida, liberar novamente quando estiver pronto.
Ambientes
Desenvolvimento Todo desenvolvedor tem seu próprio ambiente de desenvolvimento local que geralmente não será acessível fora de sua própria máquina. Você nunca "libera" o rdquo; para o desenvolvimento em si, mas você desejará ser capaz de inicializar facilmente o ambiente de desenvolvimento para que os membros da equipe possam configurar rapidamente um novo computador. Integração O ambiente de integração pode ser um sistema semi-público compartilhado, mas, na maioria das vezes, isso seria tratado por um processo automatizado chamado "integração contínua". que testa automaticamente novos códigos pelos desenvolvedores para garantir que nada seja quebrado. Semelhante ao seu ambiente de desenvolvimento, você não liberaria para o seu ambiente de integração. Em vez disso, ele monitora o sistema de controle de origem para atualizações e executa automaticamente seu conjunto de testes automatizado. Garantia de qualidade (QA) Se o seu processo estiver envolvido o suficiente, o ambiente de garantia de qualidade é um ambiente disponível internamente que fornece um ambiente consistente e estável para que seus testadores localizem e reproduzam problemas. Preparação O principal objetivo de um servidor de teste é reproduzir a produção da melhor forma possível, a fim de minimizar as surpresas das diferenças de configuração no nível da produção. Em alguns casos, para equipes menores, você pode combinar o controle de qualidade e a preparação em um único ambiente. Produção Produção é o local de descanso final onde você disponibiliza seu código para todos. Devido à necessidade de dimensionamento e confiabilidade, a produção geralmente será mais complicada que seus outros ambientes.
Implantação Contínua.
A implantação contínua é uma das configurações mais avançadas para equipes que têm qualidade e processo bloqueados. Nessas situações, as liberações são configuradas para ocorrer automaticamente se o novo código passar com sucesso em todos os testes automatizados. Para fazer isso, sua equipe precisa ter um nível incrivelmente confiável de que o novo código seja testado e esteja funcionando. Nesse cenário, sempre que alguém adicionar um novo código, ele será executado em todos os seus testes automatizados e, supondo que eles passem, coloque o código em produção.
Qual é o próximo?
Agora que lançamos as bases para as ferramentas e processos fundamentais, podemos ver como tudo se junta no contexto de um projeto real. Primeiro, discutiremos o planejamento para ver como o rastreamento de problemas pode ajudar a evitar problemas antes que eles se tornem erros dispendiosos de implementação. Mas antes de fazermos isso, vamos dar uma olhada no contexto maior de entrega de software organizado em quatro fases. Planejamento ou organização de ideias e objetivos. Criando, que é principalmente design e desenvolvimento. Revendo, ou todos os processos em torno de garantia de qualidade e testes. E, finalmente, ouvindo, onde seu código está ativo, e você tem uma variedade de monitores e ferramentas para alertá-lo sobre quaisquer problemas.
Isso deve ser uma visão geral de alto nível, independente de tecnologia, de algumas das principais facetas do moderno desenvolvimento de software iterativo. Esses ciclos ou iterações podem durar uma semana ou várias semanas. Depende inteiramente do que funciona para sua equipe.

Pesquisa nos EUA na Web para dispositivos móveis.
Bem-vindo ao fórum do Yahoo Search! Gostaríamos de ouvir suas ideias sobre como melhorar a Pesquisa do Yahoo.
O fórum de comentários do produto do Yahoo agora exige um ID e uma senha válidos do Yahoo para participar.
Agora você precisa fazer login usando sua conta de e-mail do Yahoo para nos fornecer feedback e enviar votos e comentários para as ideias existentes. Se você não tiver um ID do Yahoo ou a senha do seu ID do Yahoo, inscreva-se para obter uma nova conta.
Se você tiver um ID e uma senha válidos do Yahoo, siga estas etapas se quiser remover suas postagens, comentários, votos e / ou perfil do fórum de comentários do produto do Yahoo.
Vote em uma ideia existente () ou publique uma nova ideia…
Idéias quentes Idéias superiores Novas ideias Categoria Status Meu feedback.
Melhore seus serviços.
O seu mecanismo de pesquisa não encontra resultados satisfatórios para pesquisas. Está muito fraco. Além disso, o servidor do bing geralmente está desligado.
Rastreador de handicap de golfe, por que não posso chegar a ele?
Por que eu sou redirecionado para o PC e para o dispositivo móvel?
Eu criei uma conta de e-mail / e-mail há muito tempo, mas perdi o acesso a ela; Todos vocês podem excluir todas as minhas contas do Yahoo / Yahoo, exceto a minha mais nova YaAccount.
Eu quero todo o meu acesso perdido yahoo conta 'delete'; Solicitando suporte para exclusão de conta antiga; 'exceto' minha conta do Yahoo mais recente esta conta não excluir! Porque eu não quero que isso interfira com o meu 'jogo' on-line / jogos / negócios / dados / Atividade, porque o programa de computador / segurança pode 'roubar' minhas informações e detectar outras contas; em seguida, proteger as atividades on-line / negócios protegendo da minha suspeita por causa da minha outra conta existente fará com que o programa de segurança seja 'Suspeito' até que eu esteja 'seguro'; e se eu estou jogando online 'Depositando' então eu preciso dessas contas 'delete' porque a insegurança 'Suspicioun' irá programar o jogo de cassino 'Programas' títulos 'para ser' seguro 'então será' injusto 'jogo e eu vai perder por causa da insegurança pode ser uma "desculpa". Espero que vocês entendam minha explicação!
Eu quero todo o meu acesso perdido yahoo conta 'delete'; Solicitando suporte para exclusão de conta antiga; 'exceto' minha conta do Yahoo mais recente esta conta não excluir! Porque eu não quero que isso interfira com o meu 'jogo' on-line / jogos / negócios / dados / Atividade, porque o programa de computador / segurança pode 'roubar' minhas informações e detectar outras contas; em seguida, proteger as atividades on-line / negócios protegendo da minha suspeita por causa da minha outra conta existente fará com que o programa de segurança seja 'Suspeito' até que eu esteja 'seguro'; e se eu estou jogando on-line 'Depositando' então eu preciso dessas contas 'delete' porque a insegurança 'Suspicioun' irá programar o jogo de cassino 'Programas' títulos 'para ser ... mais.