No entanto, há muitos motivos pelos quais não só é razoável utilizar um repositório de controle de versões ainda que haja só um desenvolvedor, como é fato que é a melhor opção para um trabalho profissional.
1 –
VOLTAR AO PASSADO
O registro histórico de mudanças nos dá toda a informação sobre o que foi alterado, quando e por quê. Por exemplo, permite-nos responder a perguntas como: “O que mudei na última semana que pode ter produzido este novo erro?”
É verdade que se trabalhamos sem GXserver, GeneXus também provê um histórico de mudanças por objeto, criando uma revisão cada vez que o usuário o salva. No entanto, o histórico de mudanças em GXserver vai muito além disso porque, quando fazemos um commit, estamos definindo um grupo lógico de objetos que mudam ao mesmo tempo e com uma intenção específica e declarada (ex: comentários do commit). Os comentarios inclusive podem ter uma referência a um número de ticket de um acompanhamento de erros ou de gerenciamento de projetos.
Quando algo falha, temos tudo o que é necessário para reverter os erros. Muitas vezes, as mudanças em um objeto estão relacionadas às mudanças de outros objetos. Por exemplo, se mudamos os parâmetros de um procedimento, teremos que mudar também os objetos que o chamavam. Ter o conhecimento de quais foram os objetos modificados em cada commit, permite-nos estar seguros de que estamos corrigindo todos os objetos que precisam de alteração.
Do mesmo modo, para entender por que fizemos determinada modificação em um objeto, é fundamental a informação de contexto; ou seja, que outros objetos mudaram neste mesmo momento e qual era o estado dos que não mudaram.
2 – MELHOR GERENCIAMENTO DE VERSÕES
Claro que também podemos ter versões congeladas e novos ramos de desenvolvimento em uma KB, inclusive sem GXserver, mas, usando GXserver, obtemos a facilidade de publicar qualquer destes ramos a processos externos ou servidores de armação ou integração contínua, de forma desacoplada e sem as penalidades de performance associadas a um acesso compartilhado pela rede de uma KB.
A KB na qual desenvolvemos só precisa ter um ramo no qual estamos fazendo mudanças, enquanto que no server, podemos ter todas as versões congeladas e todos os ramos de desenvolvimento. Um servidor de integração contínua pode estar monitorando os commits que fizemos em qualquer das versões para disparar um processo de armação de versão, execução de testes, deploy, etc.
3 – LIVRE EXPERIMENTAÇÃO
Na nossa KB local, podemos experimentar e provar livremente, contando com a segurança de que nada disso afeta a versão “oficial”, ao menos que explicitamente façamos commit das mudanças. Uma vez que estamos prontos para fazer um commit, podemos revisar o reporte de mudanças pendentes de commit, comparar cada objeto com seu estado original e decidir quais incluir no commit, quais facilmente reverter a seu estado inicial e quais manter como mudanças locais.
GXserver controlará também que o conjunto de objetos incluindo o commit seja coerente (por exemplo, que não incluamos uma chamada a um objeto novo que nos esquecemos de incluir) e, em caso de qualquer erro, recusará todas as mudanças sem modificar nada, de forma a assegurar que todo commit forme uma unidade lógica de mudanças completa e que nunca perdarmos a integridade da KB do servidor.
4 – BACKUPS MAIS FÁCEIS
Nunca é necessário fazer backup de múltiplas cópias de uma mesma KB, e sempre temos certeza do que exatamente precisamos fazer cópia de segurança: as KBs administradas pelo servidor. Enquanto façamos commit e tenhamos uma política adequada de backups das KBs do servidor, estamos garantidos em relação a possíveis perdas das KBs locais, seja devido a falhas de discos, notebooks roubados ou qualquer motivo parecido.
Se utilizamos o GXserver Online (assinatura de GXserver na nuvem), contamos também com backups automáticos de todas as KBs.
5 – INSPEÇÃO ONLINE DA KB
GXserver provê uma console web pela qual podemos inspecionar as KBs, o conteúdo de seus objetos e a atividade de mudanças. Não é necessário contar com GX para isso, basta um browser. Se temos nossa instalação de GX e as KBs no escritório. Da mesma forma, podemos usar este console de casa ou quando estamos viajando.
6 – INTEGRAÇÃO DE OUTROS ATORES
Podemos dar acesso ao console de GXserver para integrar outras pessoas que, mesmo que não desenvolvam, estejam envolvidas no projeto e necessitem monitorar seu desenvolvimento, como por exemplo, um gerente ou um cliente para o qual estamos desenvolvendo o sistema.
Por outro lado, o desenvolvimento de um projeto muitas vezes requer a participação de vários outros atores que podem utilizar a console do servidor para ter acesso à informação da KB sem necessidade de que tenham a KB nem uma licença de GX. Exemplos disso podem ser os que trabalham na documentação, traduções ou em desenho gráfico.
7 – QUALQUER MOMENTO, QUALQUER LUGAR
Se somos os únicos desenvolvedores, podemos também obter uma cópia atualizada do servidor de qualquer lugar. Por exemplo, podemos ter uma KB local no escritório e outra em casa e sincronizá-las com GXserver sem esforço.
Se agregamos um novo desenvolvedor, seja de forma permanente ou temporária, é fácil obter sua KB de trabalho, a qualquer momento e em qualquer lugar.
EM RESUMO
Usar uma ferramenta de manejo de versões e a metodologia associada a isso é uma dessas coisas que às vezes parece que não vamos precisar até que começamos a usá-las. Logo nos damos conta de que as vantagens são muitas e, então, nos parece mentira que antes pudéssemos trabalhar sem ela.
Uma das vantagens mais notórias é a facilidade com que podemos incorporar o trabalho de diferentes pessoas em um mesmo projeto, fazendo com que todas elas trabalhem de forma autônoma, sem interferências, mas, ao mesmo tempo, facilitando e organizando a integração do trabalho de todos.
No entanto, as vantagens de usar metodologia e ferramentas de controle de versões são tantas, até mesmo para um só desenvolvedor, que é indispensável para um desenvolvimento de software profissional. Citamos acima apenas algumas das vantagens mais evidentes, mas, sem dúvida, pode haver muitas outras.
De fato, isso não é específico de GeneXus ou GXserver: aplica-se igualmente a qualquer desenvolvimento de software com linguagens tradicionais e, sempre que surge a pergunta a recomendação é a mesma: convém utilizar controle de versões ainda que haja um só desenvolvedor?
*Publicado originalmente em
Blog de José Lamas