Controle de subversão / fonte apenas para código de produção?

Eu me formei na faculdade em Ciência da Computação há um ano e agora estou trabalhando em uma pequena empresa de desenvolvimento web (eu e um outro desenvolvedor, além de gerentes, atendimento ao cliente e testador). Até pouco antes de começar, não havia sistema de controle de origem. Agora estamos lentamente começando a implementar o SVN, mas o outro desenvolvedor (doravante denominado Joe) insiste que o único código que deve ser confirmado em nosso repositório SVN é aquele que foi testado e aprovado como pronto para produção. Isso significa que, em projetos maiores, pode não haver confirmações por semanas ou mais.

Esta é uma prática normal? Parece-me que perdemos muitos dos benefícios do controle de origem, incluindo:

• Rastreamento detalhado do progresso do projeto
• Rastreamento de problemas conforme eles aparecem e são resolvidos
• Revertendo facilmente erros
• Fácil backup de código, para não perdermos muito se uma estação de trabalho ficar inativa
• Mais fácil identificar exatamente qual código está sendo executado em quais sites de produção, assumindo que carimbemos as revisões nos executáveis, conforme descrito aqui
• Colaboração fácil (embora não trabalhemos em equipe; são todos projetos individuais)
• Etc.

EDIT: Devo enfatizar que, historicamente, não existe um verdadeiro trabalho em equipe nesta empresa; apenas dois desenvolvedores trabalhando em projetos separados. Além disso, muitos dos projetos são pequenos e podem ser concluídos em algumas semanas. E a empresa está no mercado há mais de uma década e se dá bem sem o controle da fonte. Os projetos geralmente são concluídos dentro do prazo estimado.

Se os projetos forem concluídos dentro do prazo estimado, é seguro assumir que os clientes são clientes satisfeitos? :)

Parece que a empresa está começando a assumir novos tipos de projetos e passando por algumas dores de crescimento ou algumas "dores de mudança". Muitas suposições acontecendo aqui ... Por favor, tenha paciência comigo!

Se você está confiante de que a organização e o controle do código podem ajudar você e sua equipe internamente, o SVN deve ser considerado, IMHO. Você ganha pontos de bônus se seguir esse caminho realmente funciona e a empresa é capaz de produzir produtos de maior qualidade, tornando os clientes mais felizes!

Tenha cuidado se parece que uma luta com a gerência criará um ambiente de trabalho tenso. O fato é que os proprietários fizeram a empresa. E não apenas isso, eles fizeram uma empresa de sucesso. É improvável que eles ganhem um jackpot porque são bons em jogos de azar.

Seja respeitoso e você pode acabar sendo ouvido.

Espero que isso acabe resultando em uma equipe mais eficiente e mais feliz. Na minha experiência, isso é difícil de obter com um gerenciamento frustrado.

Joe está praticamente errado. Agora, você pode argumentar que possui uma ramificação "limpa" que representa o código testado e pronto para produção. Mas não usar o controle de origem até que as coisas estejam prontas é francamente autodestrutivo. É como tentar fazer um martini sem o gin.

O "idoso" é realmente muito pouco qualificado. Qualquer código que possa ser compilado (e passa nos testes, se houver) deve ser comprometido com o controle de origem. O controle de origem é um recurso central para o compartilhamento de código e a construção de SW de forma incremental.

O ponto positivo é separar o código de produção (última versão estável), mas, para esse caso, os sistemas de controle de origem contêm recursos como tags / etiquetas e ramificações.

Nossa equipe suspeita muito se alguém não cometer nada dentro de dois a três dias. Isso significa que ele tem alguns problemas e talvez precise de ajuda. Outro ponto de controle de origem é que geralmente é feito backup regularmente, o que não é o caso de máquinas de desenvolvimento. Se o seu disco travar, você perderá o trabalho por várias semanas.

Deixando de lado a questão de saber se Joe está certo ou errado (a propósito, ele está errado), parece-me que um acordo poderia ser alcançado se você usasse um sistema de controle de versão distribuído como Git ou Mercurial .

Dessa forma, você e o outro desenvolvedor trabalhariam em seu repositório local, comprometendo suas alterações no controle de origem com antecedência e frequência, mas não enviem suas alterações para o repositório "produção" até que sejam "testadas e aprovadas como prontas para produção". Você teria um histórico completo de tudo o que trabalhou ao longo de semanas, e Joe teria um repositório primitivo que só tinha o histórico de mudanças que foram abençoadas como prontas para produção.

Não faz sentido, pelas mesmas razões que você listou. É como usar o controle de versão sem os benefícios de usar o controle de versão.

Acredito que Joe não entendeu que os sistemas de controle de origem não são backups glorificados de versões de produção de código-fonte, mas uma ferramenta útil para programadores, colocando palavras nas etapas menores do progresso e amadurecimento do código para seus futuros colegas e colegas. Talvez Joe não esteja acostumado a trabalhar em equipes com código de outras pessoas?

Já pensou em "por que essa linha de código foi adicionada"? Localize o commit que o apresentou e veja seu comentário. Se você confirmar apenas quando estiver entrando em produção, os comentários não serão específicos o suficiente para serem úteis para você.

Eu também sugiro que você use uma ferramenta mais poderosa que o SVN. Você pode ver uma boa introdução sobre as possibilidades em http://hginit.com/ por Joel Spoelsky.

Ele usa mercurial, e há vários candidatos nos dias de hoje. O Git é considerado muito poderoso, e https://github.com/ possui algumas ferramentas muito, muito úteis e fornece contas iniciais gratuitas para que você possa experimentar de verdade.

Joe não parece saber sobre SVN, tente descobrir Ramos, Tags e Trunk ... Tags é consistente com o que Joe deseja. Algumas leituras sobre as melhores práticas de SVN não prejudicariam

Nunca usei o SVN, então não sei quais seriam os procedimentos para isso. Estamos usando o ClearCase, e a prática aqui é que cada desenvolvedor tenha seu próprio ramo de desenvolvimento, um ramo de integração ao qual fundimos quando estivermos prontos para iniciar o teste e um ou mais ramos de lançamento para código integrado e testado .

Joe é um hacker, não um desenvolvedor. Ele parece um hacker muito bom, mas ele está errado sobre como usar o controle de revisão. Então o que fazer sobre isso?

Parece-me que sua organização tem um investimento no SVN e seria uma limitação de carreira desafiar Joe e invalidar o investimento em dólar no servidor SVN. Configure um repositório GIT e use a interface git svn para funcionar da maneira que você deseja (tudo isso é software livre e leva uma hora ou um dia para ser configurado, tudo na sua estação de trabalho). Socialize seu fluxo de trabalho com Joe - ele pode preservar seu sistema de crenças de "repo SVN não poluído" e manter sua credibilidade sobre o caro elefante branco no canto (e ego).

Em pouco tempo, espero que Joe veja como você trabalha e comece a fazer o mesmo. Em um ano ou dois, o servidor SVN se tornará um repositório Git.

Você pode tentar convencer Joe com os argumentos acima. Se isso não der certo, use o SVN localmente para seu próprio trabalho de desenvolvimento e espere que algum dia seja escolhido por Joe. Se você não pode convencê-los com argumentos, faça o que você está convencido e mostre a eles que funciona. Tipo da abordagem distribuída, mas com as ferramentas existentes.

Vou ecoar o @ Carson63000 aqui e dizer que já vi essa atitude antes, e é causada em grande parte pelos horríveis recursos de ramificação / fusão do VCS. Ter uma ramificação que compila e passa nos testes, com tags para cada release, é uma ótima abordagem, mas não deve ser seguida a ponto de nenhum outro código ser confirmado. O DVCS em geral, e o git em particular, tornam a ramificação uma operação fácil e comum e reduz bastante a dificuldade desse fluxo de trabalho.

A razão pela qual os sistemas de controle de versão suportam tags é porque você pode marcar o código certificado e ainda assim ter seu trabalho diário confirmado. Sempre que você tiver um código de qualidade de produção, confirme com isso uma etiqueta e pronto. Você sabe o ponto exato no 'tempo' em que precisa voltar para obter o que o cliente tem. E você sempre pode verificar e comparar diferentes versões do seu código. Dessa forma, você pode ficar satisfeito com o que possui na base de dados de controle de origem. Funciona para a empresa em que trabalho, que possui 100 desenvolvedores, todos trabalhando no mesmo projeto. Deffinately trabalhará para você também.

É bastante comum armazenar apenas itens em sistemas de controle de versão prontos para entrega à produção. É assim que é feito historicamente há décadas, desde os velhos tempos em que o armazenamento em disco custava centenas de dólares por megabyte e o armazenamento de tudo era muito caro.

Não é mais considerada a melhor maneira de fazer as coisas, mas posso entender completamente por que as pessoas ainda o fazem, pois ainda estão em uso muitos sistemas de controle de versão mais antigos que tornam difícil, se não impossível, fazer outra coisa e ainda retêm conhecimento do que seus cada versão é (ou melhor, não há como saber o que é uma versão sem verificar as tags em cada arquivo, se você precisar voltar. Eu já vi mais de um repositório em que a única maneira de recuperar uma versão antiga release era recuperar do repositório um arquivo zip com o código-fonte e os binários para esse release).