Provisionamento de desktop para uma pequena equipe de desenvolvimento de software Linux

4

Meta: crie uma pequena equipe usando uma imagem de desenvolvimento padrão em vez de 4 desenvolvedores de software configurando seus próprios ambientes.

Por que:

  1. leva um dia ou dias para instalar uma distribuição, bibliotecas específicas de construção, ferramentas como editores e IDEs, mysql, couchdb, java, maven, python, android-sdk, etc. É uma PITA gigante que, quando repetido 4 vezes por 4 desenvolvedores (não sys admins) desperdiça tempo e gera divergências irritantes que surgem mais tarde (síndrome de builds-on-my-box).

  2. Não há compartilhamento de produtividade, configurações, truques, scripts, configurações.

Parte disso é ajudada pela segregação dos sistemas de construção em imagens sem cabeçalho da caixa virtual. Isso realmente não aborda ferramentas ou o desenvolvedor da área de trabalho GUI que precisa ser feito.

Então eu vejo três estratégias básicas, fantasmas, virtualização e, finalmente, criar uma espécie de distribuição linux interna (acho que o Google faz algo assim).

O ambiente dev de destino é baseado no Debian OpenBox e deve permitir uma mistura de notebooks de 3 gen Core i7 de no mínimo 8 GB para trabalhar tanto em single como em multihead. Importante, os lappies são não iguais, mas uma mistura de macbooks e PCs de 2012. Então:

  1. virtualização: está fazendo todo o seu trabalho dentro de uma VM, como o VirtualBox, prático neste hardware ou chato.

  2. ghosting: laptops de diferentes fabricantes tornam isso impraticável.

  3. DIY distro: curto de criar um monte de pacotes de instalação, não sei se há algum "criador de distro" que possa impedir que isso seja um projeto épico de instalação de pacotes de scripts.

Então, algum conselho?

    
por deakblue 15.09.2012 / 08:19

1 resposta

3

Este é um problema complicado, e aquele que entra direto na política muito, muito rápido. Se a cultura corporativa é muito strong nos "devs construir seus próprios, é como eles são mais produtivos" veia pode ser impossível quebrar. No entanto, como a TI está definitivamente envolvida pelo menos na configuração inicial, parece que você não está tão longe no buraco do coelho.

Eu tenho um problema parecido, embora toda a TI esteja envolvida com a configuração mais básica de um novo laptop. Não estou envolvido na configuração de ambientes dev, cada dev é responsável por isso (o que rapidamente se torna um esforço de equipe, que é uma coisa boa a seu modo).

No entanto, sem suporte explícito ao gerenciamento, tudo o que você fizer estará sujeito a convencer seus usuários com suporte de que o que você está fazendo é o melhor. Essa é uma habilidade que não podemos ensinar.

Devido à natureza do nosso trabalho, descobrimos que o desenvolvimento orientado para VM funciona muito bem. Como também temos uma mistura de laptops OSX, Windows e Linux como estações de desenvolvimento, e nos desenvolvemos em direção a uma combinação muito mais específica de ferramentas e sistemas operacionais, as máquinas virais são a maneira mais confiável de garantir que o novo código funcione a plataforma de destino.

Historicamente, as pessoas desenvolveram em um MacBook, implantaram no ambiente do Integration e passaram alguns dias trabalhando em peculiaridades específicas do Mac que não funcionam no ambiente de destino. Esse problema de "passar alguns dias" desapareceu assim que esses usuários começaram a usar as VMs.

Se o fluxo de trabalho orientado por VM funciona ou não para você depende, em grande parte, de suas práticas de desenvolvimento. Isso parece funcionar melhor se um dev:

  • Um desenvolvedor pode trabalhar em um ramo de recurso
  • É possível implantar esse ramo de recurso em seu próprio conjunto de VMs com facilidade
  • Pode mesclar sua ramificação de feição em integração / teste / qa com a mesma facilidade e pouca sintonização
  • Tem senso de estilo suficiente para não irritar os outros desenvolvedores

Quanto a "IDIs da GUI em uma VM", isso também pode funcionar. Vários de nossos usuários de Mac seguem esse caminho exato, eles têm uma VM de tela cheia em uma Tela, na qual fazem todo o seu código e usam as outras telas para coisas que não são de desenvolvimento, como navegação em stackoverflow para respostas. Isso funciona melhor se a área de transferência puder ser portátil entre a área de trabalho e a VM.

Um bom plano, por enquanto, é construir uma VM em qualquer plataforma que você esteja usando, com todas as coisas que você sempre coloca em suas novas construções. Em seguida, conecte-os para receber as atualizações de um repositório hospedado por você, para que você possa gerenciar melhor o software que é atualizado quando receber menos invasão de versão. Para o melhor efeito, inclua alguns ajustes que parecem ser comuns a alguns desenvolvedores, pois isso facilitará a batalha entre corações e mentes.

Você está lutando contra práticas arraigadas, e isso sempre vai levar algum tempo para mudar. Pelo menos, sem um pedido do On High.

    
por 15.09.2012 / 14:57