Arquivo de controle de versão e configuração pessoal

Nosso projeto usa um arquivo de configuração específico do usuário. Atualmente, este arquivo não está no controle de versão, pois é 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 recebem 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 global / padrão que estará no controle de versão e será atualizado regularmente por cada desenvolvedor que adicionar um novo módulo, e um arquivo de configuração privado que será mantido do controle de versão e conterá apenas as alterações específicas do usuário.

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

Você pode propor uma solução melhor?

O que os profissionais fazem?

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

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

• tente separar essas informações rigorosamente. Por exemplo, não use nenhum nome de módulo na sua configuração do usuário. Use os números de identificação (por exemplo, GUIDs) para se referir aos módulos e deixe esses números de identificação nunca mudarem depois de terem sido atribuídos a um módulo. Obviamente, isso provavelmente tem a desvantagem de que os arquivos de configuração do usuário perdem parte da simplicidade que podem ter agora. Talvez você precise criar uma ferramenta GUI para editar seus arquivos de configuração em vez de usar um editor de texto sem formatação.

• forneça ao formato do arquivo de configuração um número de versão e sempre que algo como o nome de um módulo for alterado, atribua a eles 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ódulos encontrados no arquivo e aumenta o número da versão posteriormente. Isso pode ser automatizado, para que o processo de atualização não perturbe seus companheiros de equipe no trabalho diário.

EDIT: depois de ler sua postagem novamente, acho que sua suposta solução é razoável, desde 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 precisar disso, eu me ateria à solução mais simples.

É uma solução razoável.

Você precisa de uma maneira de especificar os valores iniciais de qualquer novo elemento 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ê grava essas alterações na cópia local.

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

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

Temos uma solução um tanto interessante, somos principalmente desenvolvedores de PHP. Por isso, usamos o Phing, que permite criar tarefas automatizadas escritas em PHP. Portanto, em vez de fazer nossa atualização svn normal, fazemos uma "atualização phing" que chama svn update, e substitui nossas configurações pelas variáveis ​​apropriadas, por exemplo, uma configuração:

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

Portanto, todos os arquivos de configuração são versionados com essa sintaxe interessante e, em seguida, geramos um arquivo de configuração adhoc não versionado para minha instância específica, que substitui essas "variáveis" por configurações não versionadas especificadas nos 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.

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 são adicionadas, elas não quebram, seu caminho de atualização seria mais suave e seus usuários terão um fallback para quando atrapalharem também o arquivo de configuração.

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 ausentes, mas isso parece bastante pesado.

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. Portanto, basicamente, qualquer pessoa que faça uma alteração que interrompa os arquivos de configuração existentes precisará aumentar o número da versão do formato do arquivo de configuração e escrever um procedimento para atualizar os arquivos de configuração da versão anterior (renomear seções, etc.) e salvar novamente eles.

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

Normalmente, como eu vi isso é ter um arquivo de configuração com os valores padrão verificados no repositório. Estes podem ser, por exemplo, os valores necessários no servidor de teste. Então, quando um desenvolvedor fizer check-out do arquivo, ele terá 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á outras alterações nos campos que são para seu ambiente de desenvolvimento pessoal.

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

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 a estende com key3. Tudo que cada desenvolvedor precisa fazer é definir seu ambiente (neste caso, teste ou produção)

Esta é uma solução útil com base 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 fornecer um meio através do qual o usuário pode criptografar e descriptografar esses dados".

1. Crie um arquivo comfig fictício e .gitignore.
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 entrar em contato com o autor para obter a senha.
5. Ao criar o projeto, se o makefile não tiver sido executado, informe o usuário com console.error ("Falta o arquivo de configuração [conf / settings.json]! Você esqueceu de executar make decrypt_conf ?");
6. Uma verificação é descrita para garantir que o arquivo de configuração esteja atualizado.

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 comum em toda a placa, como adicionar uma nova entrada de configuração ou modificar o nome do módulo, faça a alteração e ela será aplicada em toda a placa. Se você deseja alterar uma instância / usuário, torne esse valor de configuração uma variável e altere a variável. Essa alteração será aplicada apenas à sua instância / usuário. Todos estes estão sob controle de versão. Você implanta os arquivos de configuração por push ou pull. A opção pull é semelhante ao git pull, mas para essa instância / usuário específico.

O Config fornece recursos adicionais, como comparar 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.