ti-enxame.com

É incomum uma empresa pequena (15 desenvolvedores) não usar o controle de origem / versão gerenciado?

Não é realmente uma questão técnica, mas há várias outras perguntas aqui sobre controle de origem e melhores práticas.

A empresa em que trabalho (que permanecerá anônimo) usa um compartilhamento de rede para hospedar seu código-fonte e o código liberado. É de responsabilidade do desenvolvedor ou gerente mover manualmente o código-fonte para a pasta correta, dependendo do lançamento ou da versão e outras coisas. Temos várias planilhas espalhadas por onde gravamos nomes e versões de arquivos e o que mudou, e algumas equipes também colocam detalhes de diferentes versões na parte superior de cada arquivo. Cada equipe (2-3 equipes) parece fazer isso de maneira diferente dentro da empresa. Como você pode imaginar, é uma bagunça organizada - organizada, porque as "pessoas certas" sabem onde estão as coisas, mas uma bagunça porque é tudo diferente e depende de pessoas se lembrarem do que fazer a qualquer momento. Uma coisa boa é que tudo é feito em backup todas as noites e mantido indefinidamente, portanto, se forem cometidos erros, os instantâneos poderão ser recuperados.

Venho tentando enviar por push algum tipo de controle de origem gerenciado há algum tempo, mas não consigo obter suporte suficiente para ele dentro da empresa. Meus principais argumentos são:

  • Atualmente estamos vulneráveis; a qualquer momento, alguém pode esquecer de executar uma das muitas ações de lançamento que precisamos executar, o que pode significar que versões inteiras não são armazenadas corretamente. Pode levar horas ou até dias para reunir uma versão novamente, se necessário
  • Estamos desenvolvendo novos recursos, juntamente com correções de bugs, e geralmente precisamos atrasar o lançamento de um ou outro, porque alguns trabalhos ainda não foram concluídos. Também precisamos forçar os clientes a usar versões que incluam novos recursos, mesmo que apenas desejem uma correção de bug, porque existe apenas uma versão em que estamos trabalhando.
  • Estamos com problemas no Visual Studio porque vários desenvolvedores estão usando os mesmos projetos ao mesmo tempo (não os mesmos arquivos, mas ainda está causando problemas)
  • Existem apenas 15 desenvolvedores, mas todos fazemos as coisas de maneira diferente; não seria melhor ter uma abordagem padrão para toda a empresa que todos temos que seguir?

Minhas perguntas são:

  1. É normal que um grupo desse tamanho não tenha controle de origem?
  2. Até agora, recebi apenas razões vagas para não ter controle de origem - que motivos você sugeriria poderia ser válido para não implementar controle de origem, dadas as informações acima?
  3. Existem mais razões para controle de origem que eu poderia adicionar ao meu arsenal?

Estou pedindo principalmente para ter uma idéia do porquê de tanta resistência, por isso responda honestamente.

Vou dar a resposta para a pessoa que acredito ter adotado a abordagem mais equilibrada e respondeu às três perguntas.

Desde já, obrigado

152
oliver-clare
  1. Pode não ser normal , mas como Treb diz , provavelmente não é isso incomum
  2. Como já foi dito, não há razões válidas para não ter controle de origem em uma empresa do seu tamanho. Portanto, você precisa identificar e atacar os motivos inválidos :

    a) a principal é o status quo : "se não estiver quebrado, não conserte". Isso é difícil: você pode começar a apontar todas as coisas que não estão funcionando tão bem quanto deveriam (que podem rapidamente ser rotuladas como 'pessoas negativas') ou apenas esperar que algo exploda (o que pode nunca acontecer) ou você poderia enfatizar todas as coisas que poderiam dar errado. Infelizmente, as pessoas encarregadas das pequenas empresas são relativamente impermeáveis ​​a "coisas que podem dar errado" até que realmente façam dêem errado ...

    b) ignorância/medo/incerteza : "realmente não entendemos o que é o controle da fonte; não sabemos como usá-lo; não sabemos qual ferramenta escolher; isso vai prejudicar nosso estilo ". Esta é uma das razões pelas quais eu definitivamente não os enviei aqui ! Pode ser uma tarefa bastante difícil para você, mas acho que, para maximizar suas chances, você precisa apresentar uma solução pronta, e não muitas variantes ou alternativas. Você precisa de uma idéia clara de: como deseja ajustar/transformar seu processo de trabalho para trabalhar com a ferramenta fornecida; como/se você planeja portar código existente; com que rapidez você pensa que pode 'treinar' usuários e colocá-los em funcionamento; como você pode gerenciar o período de transição (se houver); quanto é provável que "custe" (em horas, se não em dólares).

    c) pode haver outros motivos (más experiências anteriores com o VSS, por exemplo, ou ter lido 'histórias de horror' sobre ferramentas supostamente muito complicadas), mas você terá que batê-los individualmente quando os descobrir.

  3. Existem amplas razões para o controle da fonte descrito nas outras respostas. Meu conselho seria escolher os 2 ou 3 principais que poderiam realmente fazer a diferença para sua empresa e aperfeiçoá-los e apresentá-los em uma reunião a tantos colegas quanto possível. Tente provocar discussões: mesmo que não as convença imediatamente, você terá uma ideia do que podem ser os pontos negativos.

(Você leu/ouviu falar sobre A Função de Mudança ?)

108
Benjol

Não é absolutamente normal que um grupo desse tamanho trabalhe sem controle de origem - o tamanho do maior grupo de programadores que podem trabalhar efetivamente sem controle de origem é menor ou igual a um. É absolutamente imperdoável trabalhar sem controle de versão para uma equipe profissional de qualquer tamanho, e talvez eu não esteja me sentindo criativo, mas não consigo pensar em nenhuma razão para isso você gostaria de renunciar.

O controle de versão é apenas mais uma ferramenta - uma ferramenta particularmente poderosa e que oferece enorme benefícios em relação ao seu custo mínimo. Ele oferece o poder de gerenciar todas as suas alterações de maneira organizada, com todos os tipos de outras coisas úteis, como ramificação, mesclagem automática, marcação e assim por diante. Se você precisar criar uma versão a partir de várias versões atrás, poderá verificar o código a partir desse momento e apenas compilar sem ter que passar por outros obstáculos.

Mais importante, se você precisar escrever uma correção de bug, poderá mesclá-la em uma atualização sem precisar fornecer os novos recursos em que está trabalhando - porque eles estão em outro ramo e até o resto do desenvolvimento precisar preocupe, eles ainda não existem.

Você está enfrentando resistência porque está desafiando a cultura da empresa. Vai levar tempo para eles se ajustarem, não importa o que você diga. O melhor que você pode fazer é continuar pressionando e, se a empresa realmente não se mexer, encontre outro emprego que seja mais adequado ao seu nível de desenvolvedor.

185
Jon Purdy

É normal que um grupo desse tamanho não tenha controle de origem?

Na minha experiência, não é a norma, mas não tão completamente incomum quanto sugerem outras respostas aqui. A maioria das pequenas empresas usa controle de origem, mas um número significativo, infelizmente, não.

Até agora, recebi apenas razões vagas para não ter controle de origem - que razões você sugere que poderiam ser válidas por não implementar o controle de origem, dadas as informações acima?

Veja esta pergunta no SO para uma boa discussão. A resposta aceita diz:
"Não há boas razões para não usar o controle de versão. Nenhuma."

Existem mais razões para o controle de origem que eu poderia adicionar ao meu arsenal?

O consenso entre todos os desenvolvedores e gerentes de projeto que conheci e, claro, aqui sobre Programadores e SO é que o controle de fonte é uma obrigação. É um melhor aceito prática . Se alguém decide ignorá-lo, ele precisa ter alguns argumentos muito fortes e convincentes sobre por que essa é a decisão certa para ele (ou seja, um pouco mais do que 'nunca precisávamos disso, então por que os argumentos que você apresentou até agora estão focados em questões específicas, talvez você deva tentar uma abordagem mais ampla ao longo das linhas de 'todo mundo faz isso, então por que não fazemos isso também?

34
Treb

O controle de origem é bom para até uma única equipe de desenvolvedores. Qualquer sistema de controle de origem é basicamente um sistema de controle de versão que controla as alterações. Imagine um único desenvolvedor, que pode ter removido algum código e sente que o código agora é necessário. Ele pode recuperar o código antigo?

Basta procurar uma ferramenta que o ajude. O tamanho não importa em todos os lugares. A qualidade importa em todos os lugares.

27
Kangkan

Parece que você já está usando um sistema de controle de versão, mas não muito bom. As pessoas já parecem reconhecer a necessidade de controle de versão. Você só precisa apresentá-los ao próximo nível - controle de versão do software.

Se fosse eu, apresentaria o SCM como uma versão aprimorada do que eles já estão fazendo. Eu enfatizaria como o uso de uma boa ferramenta automatizará grande parte do trabalho que já está em andamento.

  • Em vez de registrar as alterações em uma planilha, o sistema SCM controla não apenas o que mudou, mas quem mudou e por quê.

  • Como bônus, você pode voltar a qualquer ponto da vida do código e ver o que realmente estava lá.

  • Em vez de ter versões diferentes de código em pastas diferentes e precisar mover/mesclar itens entre pastas para portar uma alteração, você pode manter tudo no mesmo lugar e (mais importante), deixar a ferramenta fazer a mesclagem.

Como outros já disseram, eu esperaria alguma resistência, para prototipar o sistema usando-o nas coisas que estou fazendo.

(Na verdade, coloquei meu currículo e outros documentos no SVN. Mais uma vez, desempenhei os papéis de gerenciadores de configuração e integração várias vezes.)

17
jwernerny

Até agora, recebi apenas razões vagas para não ter controle de origem - que motivos você sugeriria poderia ser válido para não implementar controle de origem, dadas as informações acima?

  • O produto que você está desenvolvendo é um sistema de controle de versão; os gerentes estão preocupados em impedir que os produtos existentes influenciem o design e a implementação do novo produto.

  • Entre os fins de semana do BASE pulando e correndo com touros, os gerentes que buscam emoções gostam de dirigir para o trabalho, imaginando se tudo já deu errado.

  • Evita aquisições hostis. Quem gostaria de adquirir uma equipe de desenvolvimento de software gerenciada dessa maneira?

Existem mais razões para o controle de origem que eu poderia adicionar ao meu arsenal?

  • Você já está controlando a versão, mas atualmente o faz da maneira menos eficiente, trabalhosa e propensa a erros que se possa imaginar. Usar um VCS economizará dinheiro, economizará tempo e melhorará a qualidade.

  • Economiza espaço em disco. A maioria dos sistemas de controle de versão salva apenas os deltas entre os arquivos. Atualmente, você está salvando uma cópia inteira de cada versão de cada arquivo. (O backup de todas essas cópias deve levar muito tempo e espaço!)

  • Vários desenvolvedores podem trabalhar no mesmo arquivo ao mesmo tempo e reconciliar as diferenças sem muita dificuldade. É claro que mesclar alterações é possível sem um VCS, mas é quase impossível acompanhar quem mudou o que, quando e por que nesse caso.

  • Dá aos desenvolvedores liberdade para experimentar novas idéias, sabendo que podem recuperar qualquer versão a qualquer momento.

  • Um processo melhor facilita a contratação e retenção de desenvolvedores talentosos.

9
Caleb

É normal que um grupo desse tamanho não tenha controle de origem?

Não definitivamente NÃO. Quando eu comecei na minha empresa atual, havia uma pessoa para quem você deveria enviar seu código alterado e ele o mesclaria. Eu poderia convencer todos dentro de dias a usar SVN.

Até agora, foram-me dadas apenas razões vagas para não ter controle de origem - que razões você sugere que poderiam ser válidas por não implementar o controle de origem, dadas as informações acima?

Acho que o motivo pelo qual você só ouviu motivos vagos é porque não há motivos válidos para não usar o controle de versão.

Há mais razões para o controle da fonte que eu poderia adicionar ao meu arsenal?

Sim, existem muitas razões.

  1. A ramificação oferece a possibilidade de desenvolver novas funcionalidades sem interferir em outros desenvolvimentos.
  2. Cada confirmação fornece informações sobre o que exatamente foi alterado, quem fez essa alteração e quando essa alteração foi feita.
  3. Você pode facilmente confirmar correções de erros e implantá-las nos clientes, além de deixar de fora a nova funcionalidade inacabada.
  4. Você pode manter versões diferentes, se os clientes tiverem medo de ir para uma versão mais recente.
  5. Você pode trabalhar no mesmo projeto (até os mesmos arquivos de origem!) Com facilidade.
  6. Você pode reverter facilmente um erro, preservando as alterações após esse erro cometido.
8
Geerten

Algumas pessoas têm dificuldade em perceber o quão ruim é o status quo até verem algo melhor para si mesmas. O que você precisa é de um bom demo. Mostre alguns exemplos reais de tarefas que poderiam melhorar. "Levei 4 horas para rastrear com nosso sistema atual, mas esse comando de controle de fonte me disse instantaneamente".

6
Karl Bielefeldt

Minha empresa usa GIT para controle de versão. A empresa é um desenvolvedor, um CEO, um segurança, uma faxineira e um recepcionista. Todos eles sou eu. O controle de versão de origem é obrigatório sempre.

5
João Pinto Jerónimo

Eu trabalho em muitos projetos sozinho e ainda uso o controle de versão. O tamanho não importa. Sempre ajuda ter controle de versão.

Há uma razão para ser o número 1 no The Joel Test: http://www.joelonsoftware.com/articles/fog0000000043.html

Além disso, torna os números 2 e 3 da lista possíveis.

5
Sarel Botha

Não usar o controle de origem está pedindo problemas, mesmo para um desenvolvedor solo. O simples fato de você poder editar impiedosamente sem arriscar perder nada compensa o esforço de aprendizado em semanas ou dias.

Dito isto, se você não pode convencer seus gerentes a introduzir o controle de fonte, faça um favor a si mesmo e pelo menos use algo como git ou Mercurial localmente - se as coisas explodirem devido à falta de controle de fonte, pelo menos você não será o quem fez isso.

5
tdammers

WTF ?! Essa pode ser a pergunta mais ridícula que eu já vi. Você precisa encontrar um novo emprego. 15 desenvolvedores ?! Você acha que é uma equipe pequena? Isso é uma loucura. O gerente deve ser imediatamente rescindido. Honestamente, vou ter pesadelos depois de ler esta pergunta. Diga-nos o produto que você vende para que todos saibamos que não o compramos! Não sei o que é mais assustador, essa pergunta ou resposta dizendo que isso não é incomum!

4
j-dog

Estávamos em uma posição semelhante com uma equipe de 6 pessoas há alguns anos atrás. Um dos desenvolvedores deu o passo de instalar o SVN em um servidor de desenvolvimento onde a pasta compartilhada estava e apenas começou a usá-la.

Todos seguiram o exemplo e pouco tempo antes de implementarmos o CI ( CruiseControl ) e revolucionarmos nosso processo de criação e lançamento para incluir automação e verificações de qualidade.

4
marc

Não consigo imaginar como 15 desenvolvedores podem trabalhar sem nenhum controle de origem. No entanto, de:

(...) usa um compartilhamento de rede para hospedar seu código-fonte (...)

Suponho que você criou seu próprio controle de versão do pobre homem como VSS (também baseado na pasta compartilhada). É arriscado e não eficiente.

Explique ao seu chefe como é ruim, invista em um treinamento de SVN ou GIT de dois dias e comece a usar o sistema de controle de versão real enquanto você ainda tem o código em condições razoáveis.

3
Michał Šrajer

Se eu não me comprometo várias vezes ao dia, ou pelo menos antes de sair para casa, sinto que ... algo está faltando, algo está errado.

Uma vez eu trabalhei em uma empresa com apenas 2 desenvolvedores (eu + administrador de cabelos compridos), em 1998. Mesmo assim, usamos svn. É tão conveniente.

Várias vezes na minha carreira perdi alguns dias de trabalho porque fiz algo como mv em vez de cp e depois rm -rf. Me fez chorar e passear pelas ruas da cidade em desespero.

Trabalhei em 5 empresas nos meus 13 anos de permanência no SE, participei de algumas conferências e nunca encontrei uma empresa que não estivesse usando controle de versão.

No entanto, minha empresa favorita de design de interiores, 20 funcionários, usa um quadro branco para gerenciamento de projetos + colaboração. Eles sabem que está errado, mas parecem não encontrar tempo para atualizar. De alguma forma, funciona embora. Não me pergunte como.

3
me1974

Seja um lider. Ser líder significa fazer o que é certo; resolução proativa de problemas. Liderança não está fazendo nada porque não há consenso suficiente. E um bom líder aprende a reconhecer situações em que se deve construir consenso e quando fazer. Esta é claramente uma situação real. A falta de controle de código explodirá em seus rostos mais cedo ou mais tarde.

Os líderes geralmente não estão em cargos oficiais de gerência. As pessoas seguirão líderes bons e decisivos, independentemente do título.

Se seus esforços decisivos são prejudicados, especialmente se for da gerência, é um sinal claro de que você pode sair dali. É um empecilho para o seu desenvolvimento profissional; Desenvolvedores competentes e gerenciamento incompetente não se misturam, e um incompetente com o poder vai ferrar você.

OK, os flashbacks estão me afetando. Assinando. Boa sorte.

3
radarbob

LordScree, estou em uma situação quase idêntica à sua, minha equipe imediata é de cerca de 15 desenvolvedores. Estou incrédulo (quase horrorizado) que o controle de fonte não seja usado. Minha resposta inicial a "deveríamos usar o controle de origem" foi "não temos tempo para implementar". Para mim, como usar roupas íntimas, o controle da fonte não é opcional. Depois de alguns meses, eu também tenho aprovação para implementar o TFS, escolhido pela organização porque é MS e vem com um teste de 90 dias. Resumindo, é muito difícil convencer uma organização da necessidade de controle de origem quando eles estão trabalhando juntos sem ela. Digo aos desenvolvedores que sempre que você se encontra fazendo backup de arquivos, especialmente com uma data no nome do arquivo ou no diretório de backup, é um exemplo de quando você coloca algo no controle de origem. Não tenho respostas brilhantes para você, mas acredito que isso é incomum. Estou travando a mesma batalha e vou mantê-lo informado sobre o progresso. E, esperançosamente, haverá algum progresso que eu possa procurar em outro lugar, porque não posso trabalhar no caos!

2
mmf
  1. Obter um cronômetro,
    • Conte o tempo gasto na planilha apenas para sincronizar versões
    • Conte o tempo que você gasta consertando versões quebradas
    • conte o número de vezes que as pessoas gritam no corredor "estou editando main.c !, apenas para garantir que ninguém mais esteja no momento!".
    • conte o número de reclamações recebidas dos clientes porque suas correções continham outras alterações
    • conte o atraso do lançamento apenas porque você não conseguiu sincronizar as versões
  2. Faça um PowerPoint com esses dados e compare com o funcionamento do vcs.
  3. Mostrar gerenciamento
2
cctv

Este é apenas um acidente esperando para acontecer. Você não tem histórico de código e, de uma só vez, um de seus desenvolvedores pode acabar com meses de trabalho. Como uma empresa pequena, você não pode pagar esse tipo de revés.

Você também está muito exposto nessa unidade de compartilhamento. Mesmo com um bom backup, quanto tempo você pode se dar ao luxo de não trabalhar. 1 hora, 1 dia, 1 semana. Quanto tempo levaria para instalar um novo servidor, restaurar a partir do backup etc. Novamente, como uma pequena empresa, você provavelmente não possui hardware extra em modo de espera e pode não ser capaz de gastar dinheiro rapidamente para obter remessas aceleradas, etc.

Pense também no armazenamento externo. Uma inundação ou incêndio não é realmente tão incomum. O que aconteceria se houvesse um incêndio no prédio depois de horas. Quantos meses de trabalho seriam perdidos. Um repositório de código gerenciado como o github seria valioso para isso. Mesmo o uso de um servidor SVN simples em um serviço hospedado seria um avanço nessa área.

2
Bill Leeper

No meu primeiro trabalho sério em 1990, eu era o único desenvolvedor trabalhando no meu departamento e não sabia usar o controle de origem.

Logo depois eu aprendi, a partir de então nunca mais vi um projeto que não o tornasse uma das primeiras coisas que eles criaram.

Quase perdi todo o meu trabalho nesse trabalho porque excluí uma pasta no nível errado. Felizmente, eu havia trazido uma cópia para casa em um disquete de 10 cm na semana anterior e fui capaz de recriar as semanas de trabalho em alguns dias longos.

Acho que consideraria aceitável se fosse o primeiro projeto para todos da equipe e ninguém soubesse melhor, mas se apenas uma pessoa pudesse realmente explicar os benefícios e a equipe ainda não escutasse, eu categorizaria novamente meu a opinião do grupo de "ingênuo" a "perigosamente incompetente" (a resistência ao uso de uma ferramenta com benefícios tão amplamente demonstrados é quase criminosa - é como se sua equipe não confiasse em "Compiladores" e insistisse em fazer tudo na linguagem Assembly ).

1
Bill K

Eu tenho convencido muito isso ... em pequenas empresas de engenharia/eletrônica, onde eles fazem muito software/hardware incorporado.

Nesses locais, o SCM não faz parte da cultura de engenharia eletrônica. Eles geralmente têm um engenheiro por projeto, que só precisa fazer backup da versão mais recente.

Portanto, ramificar/mesclar e até compartilhar código é considerado irrelevante. Além disso, essas empresas provavelmente são ISO9000, portanto o processo, embora estranho, provavelmente está documentado.

De qualquer forma, eu/outros desenvolvedores começamos a usar o SCM pessoalmente.

1
msr

temos 3 membros da equipe de desenvolvimento e usamos o controle de origem. Nos meus projetos pessoais, tenho um desenvolvedor e uso o controle de origem. Não é apenas útil para o gerenciamento de equipes, é útil para poder fazer um trabalho experimental sem medo de que você esteja destruindo alguma coisa.

A maneira mais fácil de convencer o gerenciamento? Existe menos risco para o produto em geral e aumentará a produtividade do desenvolvedor a longo prazo. Ambos também são verdadeiros e atraem os gerentes.

1
Nicholas Smith

Não é de forma alguma um cenário normal e acho que você deve dar uma dura luta para obter essa configuração em sua empresa. Ele tem benefícios de longo alcance e não faz sentido perceber o mesmo quando você se aproxima do dia do juízo final e não é a situação que se enquadra em Se não estiver quebrado, não conserte

Qualquer razão para não implementá-lo pode ser apenas uma desculpa para um mau trabalho ou um erro que está por acontecer.

Apenas diga a eles o quão bom é encontrar qual era o aplicativo em 1 de janeiro deste ano

que tal ei, essa funcionalidade foi adicionada em março, acho que precisamos expandir um pouco mais sobre isso.

Uau, esse bug 154256 foi corrigido neste commit.

posso ramificar o aplicativo e enviar a implantação sem problemas, pessoal, você pode continuar trabalhando.

Isso pode continuar indefinidamente ... (lembre-se de adicionar comentários em confirmações mais tarde, caso contrário, isso seria outra pergunta)

1
V4Vendetta

Eu uso o controle de versão para meus projetos individuais e para meus projetos de trabalho, onde temos mais de 30 a 40 pessoas trabalhando no mesmo código de uma só vez. O controle de versão tem suas vantagens organizacionais, mas a capacidade de reverter arquivos e ocultar alterações pode realmente aliviar a dor de cabeça do gerenciamento de código ... e, no final, esse é o melhor cenário para um programador, para que ele possa se concentrar apenas na codificação.

1
tori

Os motivos para apoiar a não utilização do controle de versão são bastante limitados. Tudo o que consigo pensar é no aspecto técnico das coisas.

  • Existe uma curva de aprendizado muito grande para converter o fluxo de trabalho de toda a equipe para incorporar um sistema de controle de versão que seja econômico.
  • Seu gerente de projeto não considera que seria benéfico introduzir a sobrecarga no fluxo de trabalho de gerenciamento e manutenção de um repositório. (Principalmente um problema com sistemas de versão mais antigos)

Há muitos motivos para usar um sistema de controle de versão. No mínimo, pare de mudar as coisas. Trabalhe com patches. Os sistemas de controle de versão podem fazer exatamente o que você diz que faz.

  • Você pode trabalhar na próxima versão ao mesmo tempo em que executa correções de bugs e liberá-las separadamente.
  • Em vez de mover arquivos de um local para outro para trabalhar nele, você pode criar uma ramificação e mesclá-la no mestre após a conclusão.
  • Cada desenvolvedor pode ter sua própria cópia do código-fonte para evitar que os problemas com o mesmo projeto sejam abertos em várias máquinas.
  • Acidentes acontecem, se o código ficar gravemente quebrado, tudo o que você precisa fazer é reverter para o último número de revisão em funcionamento.
  • O controle de versão funciona bem emparelhado com rastreadores de erros e sistemas de integração contínua.

Pessoalmente, como equipe de uma pessoa, use versionamento, rastreamento de bugs, integração contínua, revisão de código, verificação de consistência de código, testes de unidade, testes de Selenium, análise de código-fonte e talvez haja mais que eu esteja esquecendo. Eu admito, há uma ligeira curva de aprendizado. Há também uma troca de tempo de administração adicional necessário para as etapas adicionais que você automatiza. Na minha experiência, o esforço economizado supera o tempo adicional de administração.

1
Steve Buzonas

Wow apenas wow. Embora eu não ache que seja a melhor maneira de lidar com o controle de código, não é totalmente incomum que eu trabalhei em uma empresa com 6 desenvolvedores e nenhum controle de origem foi usado, eles meio que tinham sua própria maneira interna de gerenciar arquivos, um gerente de lançamento e outros enfeites supervisionariam todas as mudanças. De fato, o mantra era que novas funcionalidades poderiam ser adicionadas aos projetos, desde que algum tipo de opção envolvesse a funcionalidade.

Por exemplo, estávamos trabalhando em uma rede social de alto nível, escrita em PHP e o cliente desejava que a funcionalidade pudesse se inscrever em um perfil de usuário. Basicamente, a funcionalidade foi agrupada em uma verificação como esta se) (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {execute o código}

O local em que trabalhei também nunca teve mais de um desenvolvedor trabalhando por vez em um arquivo específico, principalmente tudo era modular, portanto, nesse caso, não havia necessidade de controle de origem. No entanto, acredito que as vantagens do controle de origem superam as desvantagens de não tê-lo na maioria dos casos.

O fato de sua empresa estar recorrendo a planilhas documentando alterações de arquivos e o que foi alterado quando algo como Git ou Subversion pode lidar com isso é absolutamente ridículo.

0
Dwayne Charrington

Onde trabalho, temos o mesmo problema. Atualmente, estou tentando deslizar o controle de origem "sob o radar" para solucionar os mesmos problemas que você tem. Eu uso Fossil nos projetos que desenvolvo pessoalmente.

Recentemente, instalei um servidor Fossil na LAN da empresa, agora é ainda mais conveniente. Espero que, ao demonstrar a utilidade em alguns projetos menores, minarei a resistência e nos afaste do status quo das pastas de rede.

Os maiores motivos que ouvi por não usar o Fossil ou outros VCS são:

  1. Muitos dos "programadores" são crianças de script e não entenderão como usá-lo
  2. Aqueles que poderiam aprender pensam que é um incômodo usar
  3. Essas pessoas são a velha guarda, confortáveis ​​com as pastas de rede, então todos devem estar
  4. Ninguém tem tempo para configurá-lo corretamente ou aprender a usá-lo
  5. Embora os recursos possam ser ótimos, nenhum deles é necessário

Como você pode ver, estou tentando contornar isso, demonstrando que é simples de usar, já configurado, fácil de aprender e que os recursos valem completamente a pena.

Por fim, mesmo que você não use o controle de origem, tudo está em uma árvore de rede. O Fossil pode versão tudo em toda a árvore, e você pode configurá-lo para ser executado sempre que ocorrer uma alteração no arquivo ou pelo menos a cada hora. Eu fiz isso em alguns de nossos projetos que "não precisavam de controle de origem" e acabou me permitindo reverter para uma boa versão quando algo desse errado.

Faça certo, e eles nem saberão que você fez. Então você pode ser o herói que restaura a versão quebrada, e demonstra a utilidade da sua ferramenta.

0
Spencer Rathbun

Parece que você está convencido, mas alguém da organização não está capacitando você para fazê-lo. Como você pode ler nos outros comentários, você deve fazê-lo.

Você pode encontrar algumas informações aqui: http://www.internetcontact.be/scm/?page_id=358

O fator mais importante é que seus clientes são forçados à última ramificação 'instável' e se seus contratos com eles o tornam responsável pela implantação de versões instáveis, sua empresa está perdendo dinheiro. Você realmente deve se concentrar na estabilidade da versão aqui. Esse é o principal motivo do controle de origem e, como parece, sua principal falha. Os outros não serão aprimorados muito usando o controle de origem, pois você já possui sistemas alternativos.

0
Yves

Agora que ferramentas DVCS como Git e Mercurial estão disponíveis e são incrivelmente fáceis de configurar e usar, não há realmente desculpa para nem uma equipe de 1 (!) Usar o controle de origem. Não se trata do tamanho da equipe, é sobre ter um histórico comentado de suas alterações e a capacidade de suportar fluxos de trabalho, como corrigir problemas de produção enquanto trabalhava em uma nova versão e rastrear o estado do código-fonte para diferentes versões.

Se me oferecessem um emprego em uma equipe que chegasse a esse tamanho e nenhum dos desenvolvedores sugerisse o uso de um VCS, ou se a "gerência" os impedisse, eu recusaria. Não é apenas uma maneira aceitável de trabalhar nos dias de hoje.

0
Martin

Você deve obter um controle de versão do GIT imediatamente. Você pode usá-lo mesmo no Google Code Project Hosting. Quando os outros vêem você fazendo alterações em apenas um clique enquanto copiam manualmente as coisas, talvez eles mudem de idéia sobre isso.

0
Mister Smith