Existem empresas sérias que não usam controle de versão e integração contínua? Por quê?


17

Um colega meu teve a impressão de que nosso departamento de software era altamente avançado, pois usamos um servidor de compilação com integração contínua e software de controle de versão. Isso não coincidiu com o meu ponto de vista, pois eu só conheço uma empresa que produzia software sério e também não tinha. No entanto, minha experiência é limitada a apenas algumas empresas.

Alguém conhece alguma empresa real (maior que 3 programadores) , que atua no ramo de software e não usa essas ferramentas? Se essa empresa existe, existe alguma boa razão para não fazê-lo?


3
Esses atores de software irritantes.
Lightness Races com Monica

1
os atores de software são diferentes dos desenvolvedores de software?
Aditya P

"Eu não sou um software, mas jogo um na TV !!" - Atores de software.
FrustratedWithFormsDesigner

1
Há Jayne Seymour, ela é uma atriz software sério .... ou pelo menos ela interpretou Solitare em Live and Let Die :)
Kevin D

3
Onde trabalhei há dez anos, tivemos versões noturnas em todos os sistemas suportados. Eles nunca chegaram perto de compilar. Sempre.
21711 David Thornley

Respostas:


5

Não tenho certeza se você os chamaria de um ato sério, mas o MySpace é muito ruim nessa frente: consulte http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .


1
+1 Eles estão na liga principal, pelo menos. Não achei que isso fosse possível. Uma empresa tão grande sem controle de versão. Vai saber.
Daramarak

Louco. Eu não teria acreditado, mas esse blog e as referências do artigo são confiáveis.
7111 Steve

Culpe o cachorro.
Jeffo

2
Um site para adolescentes iniciando uma banda em uma garagem é escrito no estilo de um programador trabalhando em sua garagem. Figuras.
24412 quant_dev

13

Você ficaria surpreso ao ver o que a realidade pode fazer com o senso comum ;-)

Eu acho que ainda existem algumas empresas por aí que não usam um sistema de controle de versão. Curiosamente, em todos os casos que vi até agora, não é porque eles se opõem de bom grado ao uso de tais sistemas, mas porque não sabem que existe algo como o SVN! Quanto a mim: concordo totalmente com você e não consigo imaginar uma situação em que não queira usar nenhum tipo de controle de versão. Inferno, estou empurrando meus próprios arquivos pessoais (documentos do word etc.) no meu PC doméstico para um repositório GIT.

No caso do sistema de integração contínua, é um pouco mais comum não empregá-los nas operações do dia-a-dia. Às vezes, também porque as pessoas não sabem que esse sistema existe, mas também vi casos em que a desculpa - muito questionável - por não usá-los é que "não somos suficientemente complexos" ou "está funcionando muito bem sem integração contínua, então, por que se preocupar em adicionar outra tecnologia? " É claro que não está uma avaliação realista - mas para responder à pergunta original: Não é tudo que incomum.


11
É possível que um desenvolvedor de software comum não tenha ouvido falar sobre software de controle de versão? De onde essas empresas contratam pessoas? O lado escuro da lua?
Daramarak

7
@daramarak: Muitos desenvolvedores de software (se não a maioria) não lêem livros, não navegam em blogs de desenvolvimento e não se comunicam com outros desenvolvedores (fora da empresa). Se você começar o desenvolvimento ensinando a si mesmo com um daqueles livros "aprenda visual visual em 21 dias", é improvável que ouça sobre o controle de versão. Na verdade, não me lembro de ter aprendido sobre controle de versão na universidade, há apenas 10 anos.
Joeri Sebrechts

@ joeri - felizmente não é verdade onde trabalho, mas posso acreditar em geral.
7113 Steve

@perdian - você diz "algumas empresas", mas não fornece detalhes ... você tem links para artigos, blogs, etc., nomeação e vergonha? Eu não estou dizendo que eu não acredito em você (na verdade eu não acredito em você), mas os dados é sempre bom ...
Steve

@ Steve Haigh - Não, eu não tenho nenhuma evidência "difícil". Eu vi algumas empresas mim mesmo que não use CI oder controle de versão (cujos nomes eu vou guardar para mim g ) e com um pouco de extrapolação Presumo que existem muito mais "lá fora". Eu acho que é um easiert muito para encontrar empresas que fazem uso do IC, simplesmente olhando para a lista de referências na página Jenkins por exemplo. Mas o contrário? Não há um monte de pessoas anunciando "Ei, nós não utilizar a tecnologia X" ;-)
perdian

12

Atualmente, quase todas as empresas do meu setor (bancário) usam controle de versão. Mas é certamente possível desenvolver software com sucesso sem controle de versão. 20-30 anos atrás. nós fizemos exatamente isso.

Eu diria que muitos bancos, talvez até a maioria, não usam um servidor de compilação com integração contínua. Se você já está fornecendo software com sucesso sem integração contínua, é perfeitamente racional continuar nesse caminho.


3
Não concordo que seja perfeitamente racional "continuar por esse caminho". Sim, entregar software durante os últimos X anos não significa que não funcionará nos próximos anos sem alterações. No entanto, depois de introduzir o CI nos produtos de software existentes (e bastante maduros), sempre há algo a ganhar com isso.
perdian

1
@perdian: há sempre algo a ganhar com muitas iniciativas. Então você precisa equilibrar o IC com todo o resto. Você não pode apenas afirmar que o IC oferece mais benefícios do que todo o resto. Você também precisa medir os custos de oportunidade.
RoadWarrior

1
@ SK-logic: O RCS era completamente desconhecido na época no setor bancário do Reino Unido. E desenvolvemos alguns sistemas muito grandes e robustos sem nenhum controle de origem.
RoadWarrior

1
-1: "Quase toda empresa" é uma afirmação muito ampla que está errada. Vi no ano passado algumas empresas que não usam nenhuma ferramenta de controle de versão, contando com cópias de versão em um diretório compartilhado. Sim, isso me fez chorar. Eles disseram que "o svn é muito difícil de usar". AMD. Mas ainda encontro algumas empresas assim. Não generalize, nem todos na indústria sabem o que é um sistema de controle de origem, nem aprendem nada online, nem sabem o que é uma integração contínua. (Eu concordo que é um inferno. Feliz por não estar mais lá).
Klaim

1
@ SK-logic - ... o que a RoadWarrior declarou, exceto no setor marítimo / de energia aqui. Não vou dar nomes, mas conheço pelo menos duas empresas que são dominantes em seu setor (algum desenvolvimento especializado de software) para as quais acredito que nunca usaram VCS de qualquer tipo (no seu sentido). Eles tinham maneiras de distinguir um bom código do código do trabalho em andamento.
01

7

Apenas para colocar um contraponto à resposta do @ RoadWarrior:

Eu trabalho para um banco. Passei os últimos 3 anos implementando o controle de versão e agora consegui obtê-lo em cerca de 20% da nossa base de código (que é bastante grande, temos aproximadamente 20 desenvolvedores e desenvolvemos nossos sistemas há> 16 anos)

Através de meus contatos na indústria (Banking), eu sei de uma tonelada de outros institutos financeiros que não tem o que qualquer pessoa em sã consciência iria chamar controle de versão.

Sim, nossa indústria (desenvolvimento de software) é muito mais triste do que a maioria gostaria de admitir.


Minhas condolencias. Parece que pelo menos algumas partes da indústria carecem seriamente das ferramentas. Eu acho que é a história sobre as crianças sapateiros novamente. Eu poderia perguntar o que uma pessoa louca chamaria de controle de versão?
precisa saber é o seguinte

6
Tirar manualmente uma cópia do código antes de editá-lo. Por exemplo, MyProg -> MyProd.old4
Dan McGrath

Infelizmente esta prática é mais comum do que as pessoas pensam
Craig T

3

controle de versão: em meu primeiro trabalho, há 25 anos, não havia um sistema de controle de versão como tal, mas esse era o RSX11 nos PDP-11s. No entanto, havia um nível muito alto de controle de qualidade com revisões formais de design e código (isso era na indústria nuclear).

Desde então, todo trabalho utiliza sistemas de controle de versão, incluindo SCCS, PVCS, clearcase, cvs e perforce.

Portanto, na minha experiência, o uso do controle de versão é praticamente universal no desenvolvimento sério de software.

integração contínua: isso é mais um problema, especialmente em locais com muito código legado que provavelmente nem tem muito em termos de testes automatizados. É preciso um investimento muito grande para mover o código existente para um ambiente de IC e, embora provavelmente seja útil no final, é difícil convencer a gerência a se comprometer com esse investimento sem obter ganhos a curto prazo.

Eu trabalhei em um local (um grande banco) que possuía IC em alguns projetos e implementamos um tipo de sistema de CI em nosso projeto que facilitou muito as coisas, mas levou cerca de 6 meses para ser feito.


Para os locais com código legado, eles criaram versões automatizadas ou tinham um plano manual de criação / implantação?
precisa saber é o seguinte

3

Eu imagino que a maioria das empresas não usa essas coisas, porque elas não entendem os benefícios e seus desenvolvedores não querem aprender ou têm medo de "mexer no pote", fazendo coisas diferentes de como estão sendo. feito antes.


3
Absolutamente! Ouvi a resposta (ou talvez devamos chamá-la de desculpa esfarrapada) "ainda não a usamos e, desde que funcionou (de alguma forma), não precisamos dela". É uma pena a resistência das pessoas contra a mudança de suas ferramentas.
perdian

1
Eu não suporto pessoas assim; infelizmente, esse é o tipo de "desenvolvedor" que encontrei com muita frequência em minha carreira, e simplesmente não consigo lidar com a ignorância deles e sempre procuro sair de uma empresa onde esses tipos de desenvolvedores são predominantes. Correndo o risco de parecer absolutamente hostil, esse tipo de pessoa é um câncer nessa profissão.
Wayne Molina

2

Embora eu seja um funcionário agora, costumava trabalhar por conta própria como consultor de banco de dados. Durante esses muitos e muitos anos, estive em algo entre 800 e 1000 empresas, desde o nível de mãe e filho até a Fortune 100.

Vi relativamente poucos lugares que faziam integração contínua, mas não me lembro de ter visto uma empresa que não usava controle de versão. Eu vi alguns onde não havia repositório centralizado para código controlado por versão. Programadores individuais usavam o controle de versão em seus próprios computadores ou mantinham o código controlado por versão em algum lugar abaixo do diretório inicial no servidor.

Eu não acho que nenhuma dessas empresas estivesse no negócio de software, mas seus programadores certamente estavam.


1

Um colega meu teve a impressão de que nosso departamento de software era altamente avançado, pois usamos um servidor de compilação com integração contínua e um software de controle de versão.

Não, eu odeio dizer isso, mas isso é verdade. Nos últimos dois lugares em que trabalhei (uma divisão de um banco e uma empresa financeira), fui eu quem implementou o sistema de controle de versão. Vários locais (especialmente lojas que não são de software) não entendem por que é realmente necessário para o desenvolvimento a longo prazo. A equipe normalmente começa como uma ou duas pessoas e depois cresce a partir daí, ainda que dolorosamente. Com uma ou duas pessoas, você pode sobreviver (não muito bem) sem ela, porque pode estar em comunicação quase constante entre si.

A construção contínua é um caso totalmente diferente. Se eu tivesse que adivinhar, apostaria que quase 90% dos locais onde o desenvolvimento é feito não tem uma solução de IC em vigor. Eu vou a conferências e a maioria das pessoas fica impressionada com o fato de uma organização que não seja um MS ou o Google. O que eu descobri é que a gerência não quer gastar a pequena quantia em dinheiro para colocá-la em funcionamento, mesmo que isso economize muito tempo.

Os maiores motivos que encontrei para isso são:

  1. As pessoas na gerência subiram na hierarquia da mesma organização. Eles nunca usaram e não precisaram, por que precisariam mudar agora? Alguns que eu encontrei têm apenas medo de mudar. Algo novo é assustador e os impediria de tirar o pó de seu antigo compilador e ajudar os mais jovens em momentos de necessidade. Outras vezes (e com mais frequência), eles têm orçamentos sempre apertados e precisam tomar decisões sobre onde gastar dinheiro. Para nós, implementar essas é uma necessidade óbvia, mas é porque as usamos antes. Conhecemos os benefícios, eles não.

  2. Os gerentes são pessoas que não são de TI e tudo o que eles fazem aqui é que você deseja gastar dinheiro com algo que não era necessário antes.

A maioria dos argumentos que ouvi de pessoas se concentram nas melhores práticas, etc., e essas são verdadeiras, mas o que a maioria dos desenvolvedores não entende é que você precisa defini-la em termos de uma situação financeira quando está nesse cenário. Com essa quantia de dinheiro que você gastará, economizaremos X e você precisará de números para fazer o backup. Isso nem sempre é verdade, mas tem sido minha experiência no passado.


Eu posso imaginar que problemas como esse surgem quando há uma comunicação deficiente do desenvolvedor e para cima nos gerentes. Felizmente, nem todas as empresas são assim. Onde trabalho, é esperado (se não for obrigado) que informe a gerência se algo pode nos tornar mais eficazes.
precisa saber é o seguinte

1

Eu diria que muitas pessoas não usam o controle de origem porque podem estar codificando por conta própria e estão acostumadas a fazer backup da base de código em um servidor central ou disco rígido USB periodicamente. Há um ano, me forcei a começar a usar o SVN porque sabia que seria benéfico a longo prazo. Demorou um pouco para me acostumar, mas agora tenho um monte de histórico de código que posso referenciar constantemente. Gostaria agora de tê-lo implementado há quatro anos quando comecei.

Integração contínua? Use-o apenas se precisar. Para mim, existem apenas dois engenheiros de software, portanto não nos beneficiaríamos da integração contínua, porque trabalhamos em nosso próprio software.


1
A integração contínua deve identificar erros quando eles ocorrerem. Até dois desenvolvedores precisam disso.
precisa saber é o seguinte

1
@daramarak: Não se os dois engenheiros estiverem trabalhando independentemente em dois produtos separados que não estão integrados.
11557 Brian

1
O CI é uma daquelas coisas que estou disposto a prescindir. Pessoalmente, eu adoraria tê-lo no meu trabalho, mas isso não vai acontecer tão cedo. No entanto, temos compilações automáticas 1-2 vezes por dia, e isso é realmente suficiente para nossas necessidades.
Michael K

1
Com uma construção automatizada, você está no meio do caminho. Basta saber que tudo o check-in compila pode ser uma alegria vezes ( "Ele compila na minha máquina")
daramarak

1

Ha, você acha que está avançado porque tem SCM e um sistema de CI? Deixe-me dizer-lhe que é hora amadora quando se trata disso.

Muitas empresas fazem o mínimo necessário, porque é tudo o que realmente precisa . Se funcionar, e você obter boas versões reproduzíveis sem grandes esforços, não há nada que precise ser corrigido. A última coisa que você deseja fazer nessas circunstâncias é começar a "consertar" as coisas, especialmente quando se trata de tirar recursos administrativos do trabalho deles para configurar e administrar seus novos servidores e criar sistemas.

No entanto, algumas empresas exigem sistemas um pouco mais rigorosos, uma vez que não apenas fazem a compilação, mas controlam os requisitos até a implantação por meio de planos e resultados de testes, analisando o código, procedimentos de check-in no estilo do fluxo de trabalho e líder de equipe designado gerenciamento de pacotes de trabalho. É um gerenciamento de configuração real e fique feliz por não precisar trabalhar nesse tipo de ambiente!

Já trabalhei em algumas empresas e não consigo pensar em nenhuma que não tenha alguma forma de SCM. Alguns deles eram mais abrangentes que outros, mas todos tinham um sistema que funcionava bem para eles, mesmo os que usavam o VSS.


ri muito ! assinado: um profissional.
deadalnix

Eu concordo, o SCM e um rastreador de erros são o equivalente ao desenvolvimento de usar calças para trabalhar. O IC é a automação básica de uma função crítica. Como backups automáticos, mas para lançamentos. Ah, reuniões do CCB. Toda semana, como um relógio.
precisa

1

Mesmo com dois programadores quando você trabalha em aplicativos complexos e uma lista de tarefas, pode ser difícil não alterar as mudanças um do outro.

Até nosso antigo software de gerenciamento de versões mostrava as alterações lado a lado e permitia que elas fossem aplicadas em qualquer direção. As alterações teriam sido perdidas em mais de uma ocasião sem ela.

Vejo vários benefícios advindos da CI, mas não consigo imaginar por que nenhuma empresa não faria uso do software de controle de versão.


1

O último trabalho em que trabalhei sem controle de versão foi em 2006 (sou desenvolvedor da Web, FWIW). A empresa tinha apenas 2 ou 3 desenvolvedores antes de me contratar, mas eu fui o primeiro de 10 desenvolvedores contratados em apenas alguns meses. Uma das primeiras coisas que fiz quando fui contratada foi introduzir o controle de versão (CVS, porque eu não sabia o quanto isso era péssimo!), Mas muitos dos desenvolvedores contratados depois de mim não conseguiram fazê-lo funcionar em seus desenvolvedores. ambientes, então não o usei. Ah, mencionei que eles nem tinham instâncias locais do aplicativo em execução? Eles invadiram o código no servidor. E sem testes automatizados, é claro. Eu me encolho quando penso nisso.

Antes disso, fiz alguns trabalhos de programação do AS / 400 sem controle de versão. Não sei se um VCS decente estava disponível para esse ambiente.

Agora eu uso o Git para todos os meus projetos individuais, e meus últimos trabalhos também o utilizaram.

O IC é uma questão diferente. É ótimo ter, e eu o incentivo, mas é menos essencial que o controle de versão, pelo menos para projetos menores em linguagens interpretadas. A maioria dos meus trabalhos recentes teve servidores de IC; entre outras coisas, significa que ninguém pode esquecer de executar o conjunto de testes completo antes da implantação.


'CI é uma questão diferente. É ótimo ter, e eu o incentivo, mas é menos essencial que o controle de versão, pelo menos para projetos menores em linguagens interpretadas. ' Acordado. O IC é realmente necessário apenas quando você está realizando compilações frequentes e / ou complexas e começa a consumir muito do seu tempo, ou você deseja executar uma suíte de testes ou deseja montar várias ramificações etc. Como um projeto PHP possui uma dúzia de desenvolvedores, não há suíte de testes e você avança para a produção uma vez por semana, provavelmente desejará se concentrar em um bom fluxo de trabalho de controle de qualidade antes de começar a se preocupar com o IC.
Siliconrockstar

E provavelmente você desejará se concentrar em um bom conjunto de testes antes de começar a se preocupar com o controle de qualidade ou qualquer outra coisa.
Marnen Laibow-Koser

Talvez em teoria, mas se você estiver usando software de código aberto, a menos que seja fornecido com um conjunto de testes, isso é praticamente impossível. Eu nunca trabalhei em um projeto PHP que tivesse cobertura de teste adequada e completa, mas todos os projetos em que trabalhei tiveram algum nível de controle de qualidade.
Siliconrockstar

@siliconrockstar Eu estava falando sobre ter uma boa suíte de testes para seu próprio código; O nível apropriado de teste para o código da biblioteca é outra questão.
Marnen Laibow-Koser

@siliconrockstar Pelo que vale a pena, a maioria dos projetos Rails em que trabalhei tiveram uma excelente cobertura de teste de desenvolvedor (as exceções estavam ativamente tentando melhorá-lo); nem todos tiveram controle de qualidade formal. É muito menos necessário ter um controle de qualidade formal com bons testes, embora ainda seja uma ideia muito boa. No entanto, o desenvolvimento sem testes é incrivelmente arriscado, por isso digo que a melhoria dos testes deve ser priorizada em relação a qualquer outra coisa.
Marnen Laibow-Koser

0

Definitivamente, encontrei alguns aqui e ali, mas principalmente pequenas empresas. O problema que vejo com mais frequência são as empresas que realmente têm SCM, mas consideram muitos projetos pequenos demais ou sem importância para acompanhar neles.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.