Como você gerencia os garfos locais do software?

Question

Como administrador do sistema, muitas vezes tenho que modificar programas para minha empresa.

Exemplo:

Estamos usando uma interface da web para gerenciar nosso DNS local.

Depois de baixar e extrair o arquivo tar.gz da internet, eu tenho que fazer algumas mudanças: eu adicionei um conector LDAP, mudei alguns arquivos de template, adicionei alguns rodapés customizados, adicionei uma tabela adicional no banco de dados, etc. .

Muitas modificações tornam-se difíceis de acompanhar.

• Existe uma maneira de lidar facilmente com atualizações de software com tantas modificações?
• Como manter minhas modificações na próxima versão do software?

Mais algumas informações:

• fonte de softwares são múltiplos (github, sourceforge, etc)
• Somos mais de um sysadmin
• sistemas de controle de versão são bem-vindos

Answer 1

Is there a way to handle software updates easily with so many modifications?

Qualquer VCS com bons recursos de mesclagem de ramificação. Qual selecionar - depende de muitos fatores e hábitos

How to keep my modifications upon next software release?

No mundo SVN, ele é chamado de "Filiais de fornecedores" - suas alterações em uma ramificação, upstream em outra, você atualiza a ramificação de fornecedor e mescla-se com o seu (leia SVN-book ou Google sobre detalhes)

No DVCS-world você pode usar técnicas diferentes

• ramificações, como no SVN
• patch & patch-management

A maneira mais fácil ( para mim , após alguns testes) é mercurial + MQ:

• minhas alterações são configuradas com patches MQ na fila do MQ, o repo é um clone puro do upstream
• para cada sincronização com upstream eu removo patches aplicados do repositório, puxo fontes, reaplico patches (com resolução de conflito de mesclagem, se necessário, e salvando patches editados), exporto dica para o conjunto não-versionado e copia para o destino final

Answer 2

Use o controle de versão.

Se houver um sistema de controle de versão atual em vigor para o desenvolvimento, use isso.

Se já não houver um, pense em usar o git.

Por que git? Há tanto ou tão pouca sobrecarga administrativa quanto você precisa. Você pode executar um servidor central ou não. Você decide. O SVN é uma boa alternativa (e amplamente implementada), mas pode ser mais difícil de manter.

Independentemente do seu VCS, você deve criar uma estrutura de diretórios básica como esta:

OPS
|
+ -- Systems
|    |
|    + -- Server2
|         |
|         + -- etc
|              |
|              + -- httpd
|                   |
|                   + httpd.conf
|
+ -- Services
     |
     + -- httpd
          |
          + -- mods
          |
          + -- patches

Eu construí algo assim para acompanhar todas as minhas configurações nagios. Funcionou perfeitamente.

Aqui está um exemplo simples no git, digamos que você acabou de instalar um servidor web e deseja fazer o backup da configuração.

cd /etc/httpd/
git init
git add .
git commit -a -m "Initial baseline"

Agora, cada vez que você alterou o arquivo (todas as vezes que você alterar o arquivo, não importa o quão trivial). Execute este comando:

git commit -a -m "Enabled mod_cgi and debugging for ticket 17789"

Agora você está mantendo várias versões dos arquivos / etc / httpd no diretório / etc / httpd (especificamente no diretório /etc/http/.git). Isso pode ficar fora de controle com > 10 git repos, então eu gostaria de começar um servidor git.

Como benefício adicional (de configurar um servidor), suas alterações de configuração agora podem ser enviadas e recebidas de qualquer local. Você não precisa mais fazer o ssh em uma máquina para editar arquivos de configuração, e você pode facilmente executar diffs de qualquer lugar. Se você trabalha em uma equipe grande, também pode acompanhar e mesclar alterações.

Aqui estão alguns artigos para você começar com o git:

Git é mais simples do que você pensa.

Como entrar no git

site principal do git

    

Answer 3

A única coisa que você precisa é de um processo de compilação repetível que retire a fonte do upstream e aplique suas correções, em ordem, até que você obtenha o resultado desejado. (Isso implica que você precisa rastrear suas próprias mudanças na forma de correções, é claro.)

Isso pode ser algo tão simples quanto um script de shell que executa os comandos apropriados, ou você pode se envolver mais com ele e construir um pacote .rpm / .deb / whatever nativo que lide com estas etapas para você. Eu geralmente faço o segundo caminho, já que há muitos outros benefícios para as embalagens que eu gosto de alavancar.

Eu recomendo criar seus arquivos .patch incrementalmente e mantê-los pequenos e relacionados a partes específicas da funcionalidade, para reduzir o impacto de conflitos de mesclagem quando o upstream lança novas versões. Se você tentar fazer isso com um patch gigante do padrinho que contém todas as alterações que você fez no software, ele nunca será aplicado corretamente.

Além disso, é apenas diligência e atenção às fusões que não funcionam. Não faria mal escrever seus próprios testes de regressão para qualquer coisa que você tocar, mas isso é a seu critério.