Controle de versão e arquivo de configuração pessoal

36

Nosso projeto usa um arquivo de configuração específico do usuário. Este arquivo não está no controle de versão, já que é diferente para cada usuário. O problema é que, sempre que um desenvolvedor adiciona um novo módulo que requer configuração ou altera o nome de um módulo existente, os outros desenvolvedores obtêm erros porque seus arquivos de configuração privados não são atualizados.

Para resolver o problema, pensamos em trabalhar com dois arquivos de configuração: um arquivo de configuração padrão / global que estará no controle de versão e será atualizado regularmente por cada desenvolvedor que adiciona um novo módulo e um arquivo de configuração privada ser mantido fora do controle de versão e conterá apenas as alterações específicas do usuário.

No entanto, isso ainda parece ser uma solução ad-hoc.

Você pode propor uma solução melhor?

O que os profissionais fazem?

    
por Erel Segal-Halevi 27.03.2012 / 13:38
fonte

9 respostas

22

Embora você já tenha algumas boas respostas aqui, a maioria delas não tem a causa do problema: seus arquivos de configuração parecem conter mais do que apenas informações específicas do usuário, eles também contêm informações (talvez redundantes) que estão na versão controle em outro lugar, provavelmente em arquivos diferentes, como nomes de módulos.

Posso pensar em duas soluções possíveis aqui:

  • tente separar essa informação rigorosamente. Por exemplo, não use nenhum nome de módulo em sua configuração de usuário. Use números de identificação (por exemplo, GUIDs) para se referir a módulos e deixe que esses números de ID nunca mudem depois de terem sido atribuídos a um módulo. Claro, isso provavelmente tem a desvantagem de que os arquivos de configuração do usuário perdem um pouco da simplicidade que podem ter agora. Você talvez precise criar uma ferramenta de GUI para editar seus arquivos de configuração em vez de usar um editor de texto simples.

  • dê ao seu formato de arquivo de configuração um número de versão, e sempre que algo como um nome de módulo for alterado, atribua a ele um novo número de versão. Em seguida, você pode fornecer um script de atualização que verifica os números de versão e, se o arquivo de configuração não estiver atualizado, ele altera todos os nomes de módulo encontrados no arquivo e, posteriormente, aumenta o número da versão. Isso pode ser automatizado, portanto, o processo de atualização não afetará seus colegas de equipe no trabalho diário.

EDIT: depois de ler sua postagem novamente, acho que sua suposta solução é razoável, contanto que novos módulos sejam adicionados, mas não renomeados. O que escrevi acima permitirá alterar os nomes dos módulos ou a estrutura da configuração dos módulos existentes posteriormente. Mas se você não precisa disso, eu manteria a solução mais simples.

    
por 27.03.2012 / 14:25
fonte
11

É uma solução razoável.

Você precisa especificar o (s) valor (es) inicial (is) de qualquer novo (s) elemento (s) de configuração. Eles precisam ser armazenados em algum lugar e um arquivo de configuração global, somente leitura, é a escolha óbvia.

Então, quando cada usuário altera sua configuração pessoal, você escreve essas alterações em sua cópia local.

Seu código precisará ler a configuração global primeiro e a configuração específica do usuário para sobrescrever quaisquer valores alterados. Isso será muito mais simples do que ler o local e, em seguida, tentar descobrir quais não foram definidas e, portanto, precisar ler o arquivo de configurações globais.

Se você usar algo como XML para o armazenamento, não precisará se preocupar em lidar com o caso em que remove as configurações. Eles não serão solicitados da cópia de usuários do arquivo e, se você recriar o arquivo, eles serão removidos na primeira vez que o aplicativo for usado após a alteração.

    
por 27.03.2012 / 13:48
fonte
3

Nós temos uma solução um tanto interessante, nós somos principalmente desenvolvedores PHP, então nós usamos o Phing que permite criar tarefas automatizadas escritas em PHP, então ao invés de fazer a nossa atualização svn normal, nós fazemos uma "atualização phing" que chama svn update, e então substitui nossas configurações pelas variáveis apropriadas, por exemplo, uma configuração:

$db_user = "${test.db_user}";

Portanto, os arquivos de configuração são todos versionados com essa sintaxe interessante e, em seguida, geramos um arquivo de configuração não versionado ad hoc para minha instância específica, que substitui essas "variáveis" por configurações não versionadas especificadas em arquivos ini não versionados. Dessa forma, podemos modificar qualquer arquivo específico do usuário e fazer com que as alterações sejam preenchidas em outras cópias de trabalho.

    
por 28.03.2012 / 02:34
fonte
2

O programa deve ter uma configuração padrão no código para quando o valor não for encontrado no arquivo de configuração. Dessa forma, à medida que novas coisas forem adicionadas, elas não serão interrompidas, seu caminho de upgrade será mais suave e seus usuários terão um fallback para quando eles bagunçarem o arquivo de configuração também.

Outro exemplo mais complexo seria na inicialização do programa ou em algum outro ponto-chave, abra o arquivo de configuração usando um módulo de inicialização e adicione os padrões que estão faltando, mas isso parece muito pesado.

    
por 27.03.2012 / 14:24
fonte
2

Coloque um número de versão no arquivo de configuração pessoal (o número da versão do formato do arquivo de configuração).

Faça o código que processa o arquivo de configuração pessoal verificar o número da versão e, se estiver desatualizado, execute um procedimento de atualização. Então, basicamente, qualquer pessoa que fizer uma alteração que interromperá os arquivos de configuração existentes precisará aumentar o número da versão do formato de arquivo de configuração e gravar um procedimento para atualizar os arquivos de configuração da versão anterior (renomeando seções, etc.) e salvar novamente eles.

Você provavelmente desejará algum processo como este para os usuários finais, portanto, é melhor usá-lo para facilitar a vida de seus desenvolvedores.

    
por 28.03.2012 / 02:11
fonte
1

Normalmente, como eu já vi isso é ter um arquivo de configuração com os valores padrão verificados no repositório. Estes poderiam ser, por exemplo, os valores necessários no servidor de teste. Então, quando um desenvolvedor faz check-out do arquivo, eles terão todos os valores. Se um novo campo for adicionado ou um campo for removido, isso será tratado em uma mesclagem. Um desenvolvedor verificará o valor necessário para o servidor de destino e não verificará quaisquer outras alterações nos campos que são para seu ambiente de desenvolvimento pessoal.

É preciso garantir que a mesclagem seja feita corretamente, mas parece bastante seguro para mim.

    
por 27.03.2012 / 13:48
fonte
1

O que fazemos aqui é criar blocos de configurações. Isso pode ser feito no Zend assim:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

Isso significa que o teste herda a produção e o estende com key3. Tudo o que cada desenvolvedor precisa fazer é configurar seu ambiente (teste ou produção, neste caso)

    
por 27.03.2012 / 13:53
fonte
0

Esta é uma solução útil baseada no post: Mantendo senhas no controle de origem

Em resumo, a estratégia é "manter uma versão criptografada do arquivo de configuração no controle de origem e, em seguida, fornecer um meio pelo qual o usuário possa criptografar e descriptografar esses dados".

  1. Crie um arquivo comfig fictício e .gitignore-o.
  2. Crie um makefile que possa criptografar e descriptografar o arquivo de configuração
  3. Armazene o makefile e o arquivo de configuração criptografado no repositório
  4. O makefile pede uma senha e como contatar o autor para a senha.
  5. Ao construir o projeto, se o makefile não for executado, informe o usuário console.error ("Arquivo config [conf / settings.json] faltando! Você esqueceu de executar make decrypt_conf ?");
  6. Uma verificação é descrita para garantir que o arquivo de configuração esteja atualizado.
por 28.06.2013 / 19:51
fonte
0

Criamos uma ferramenta chamada Config que lida com problemas de configuração como este. O que você fará é criar (ou importar) 1 arquivo de configuração principal. Em seguida, crie um ambiente chamado Local. No ambiente Local, crie várias instâncias, uma instância por usuário. Se você precisar fazer uma alteração que seja comum em toda a linha, como adicionar uma nova entrada de configuração ou modificar o nome do módulo, basta fazer a alteração e ela será aplicada em toda a linha. Se você quiser fazer uma alteração de instância / usuário, torne esse valor de configuração uma variável e, em seguida, altere a variável. Essa alteração será aplicada somente à sua instância / usuário. Todos estes estão sob controle de versão. Você implanta os arquivos de configuração via push ou pull. A opção pull é semelhante ao git pull, mas para essa instância / usuário específico.

O Config oferece recursos adicionais, como comparação de configurações entre usuários, pesquisa, marcação, validação e fluxo de trabalho. É SaaS, portanto, não é realmente para aqueles que ainda não estão prontos para a nuvem, mas temos um plano local.

    
por 23.02.2018 / 06:21
fonte