Gestão de Projetos com GeneXus

O desenvolvimento de software é uma atividade que possui um alto custo, alta complexidade, demanda muito tempo, recursos caros e escassos.
Os sistemas são extremamente dinâmicos, estão em constantes mudanças. Há necessidade de prover uma resposta rápida e de qualidade para as solicitações de mudanças, contudo sem negligenciar os controles.

O impacto gerado por um erro pode ser catastrófico. 

Uma maneira de prover estabilidade à evolução de um software desenvolvido e mantido por uma equipe de desenvolvedores é aplicando a disciplina SCM (Software Configuration Management).  SEI (Software Engineering Institute)

O Cenário Enfrentado Pelos Desenvolvedores

Os desenvolvedores GeneXus encontravam alguns problemas clássicos no processo de desenvolvimento de software como, por exemplo:

• Precisamos gerar um novo build para o cliente com a última versão do sistema.
• Qual a versão correta deste arquivo?
• Quais arquivos foram modificados?
• O que foi modificado?
• Quem modificou estes arquivos?
• Por qual motivo?
• Quando?

O desenvolvimento de software é um trabalho em equipe e certo grau de confusão é inevitável como, por exemplo:

• Não posso reproduzir o erro nesta versão!
• O que passou com a correção da semana passada?
• A aplicação em execução não é compatível com o código fonte.
• Realmente estamos trabalhando na última versão?
• Este programa antes funcionava!

Nesse contexto, GeneXus carecia de um mecanismo de controle que pudesse controlar os releases de um produto bem como as mudanças durante o ciclo de desenvolvimento. E também, necessitava de um esquema de identificação que pudesse refletir a estrutura do produto.

O trabalho em equipe, o desenvolvimento multiusuário, era outro item que carecia de um controle das interações entre múltiplos analistas e programadores.

Conclusão: O ciclo de desenvolvimento é um processo dinâmico que requer controle das modificações realizadas nos objetos do projeto.
Solução: Software Configuration Management (SCM).

O Novo Cenário, Gerenciamento de Versões da Knowledge Base

Figura 1 – Versionamento da KB

O desenvolvimento da aplicação começa seguindo uma linha principal de desenvolvimento (linha do meio Trunk, Figura 1), lugar onde são adicionadas as funcionalidades requeridas e utilizam-se protótipos para testes.

Em determinados momentos deste ciclo surge à necessidade de estabelecer um checkpoint no processo, seja pela liberação de uma versão, a entrega de uma versão a um cliente, a necessidade de congelar um determinado estado da aplicação, etc. Então, o que fazemos é congelar o produto nesse momento criando, por exemplo, a versão 1.0, entrega-se a um cliente e continua-se o processo de desenvolvimento principal.

Em outro momento surge a necessidade de realizar correções sobre a versão entregue ao cliente (versão 1.0), pelo que é necessário abrir uma nova linha de desenvolvimento para incluir estas correções sobre o que era a versão 1.0 sem afetar a linha de desenvolvimento principal que seguiu crescendo desde o momento do congelamento da versão 1.0.

Então, é criado o que se conhece como Development Version ou Branch, que é simplesmente uma nova linha de desenvolvimento paralela a principal.

Durante o transcorrer do projeto voltam a aparecer requerimentos deste tipo, seja por determinação de checkpoints como a necessidade de abrir novas linhas de desenvolvimento, por exemplo, cria-se a versão 1.1 ou a 1.0.1 que vem a ser um congelamento da linha de desenvolvimento aberta a partir da versão 1.0 e assim sucessivamente até ter a situação como à exemplificada na Figura 1. 

Estas situações formam parte da operação normal no desenvolvimento de uma aplicação e é necessário administrar facilmente este processo. Para isto, na nova versão de GeneXus, GeneXus X, foi introduzido o conceito de Gerenciamento de Versões. As versões se classificam em:

• Development Versions, representam as linhas de desenvolvimento da aplicação, as quais são independentes entre si, existe uma linha principal e várias paralelas, a principal vem a ser o que se conhece como Trunk e as demais o que em SCM se conhece como Branch.

• Frozen versions, também conhecidas como Labels em SCM, representam os congelamentos criados em determinados momentos do processo sobre as Developement Version para determinar certos checkpoints (liberação de versão, entrega a um cliente, congelar estado, etc.).

Com o GeneXus X, os desenvolvedores também podem identificar falhas da aplicação e rendimento, e gargalos da aplicação materializados em um depurador de aplicação tornando a experiência em desenvolvimento uma tarefa mais simples: Debugging, para entender como está sendo executado um programa; Profiler, para corrigir erros de performance.

E com o recurso Change Defender, os desenvolvedores poderão integrar bases de conhecimentos através do recurso de merge das KBs.

Histórico e Comparação de Versões de Objetos

O GeneXus X mantém um controle das alterações realizadas em cada objeto GeneXus.

Cada vez que um objeto GeneXus é salvo cria-se uma versão e guarda-se a versão anterior (apenas como leitura) com as seguintes informações:

• Data e hora de modificação.
• Autor.

Para comparar as versões de objetos GeneXus, é utilizada uma ferramenta sofisticada e de fácil utilização que se encontra integrada ao GeneXus chamada Comparison Tool.

Na ferramenta Comparison Tool é possível comparar regras, eventos, form e propriedades dos objetos GeneXus.

Com esta ferramenta o desenvolvedor poderá incluso, voltar a uma versão anterior do objeto, caso seja necessário. Se o desenvolvedor marcar uma versão antiga do objeto como ativa, será criada uma nova versão desta versão antiga, já que as versões do histórico são read-only.

Trabalho Em Equipe no GeneXus X

Para possibilitar um eficaz e eficiente trabalho em equipe, GeneXus conta com um novo produto chamado GeneXus Server.
A integração e coordenação de diferentes modificações durante o desenvolvimento em grande escala é uma necessidade imprescindível que é suprida com GeneXus Server.

Ao existir um conjunto de analistas e desenvolvedores que trabalham desde diferentes pontos geográficos em uma mesma KB (Team Working), a implementação de GeneXus Server pode resultar altamente útil por suas possibilidades de trabalho em equipe, pela facilidade do acesso remoto para operar outorgando estabilidade e confiança ao processo de integração.

Outros possíveis cenários de trabalho com GeneXus Server são expor os dados da base de conhecimento como serviço (Data Services sobre uma KB) ou modificar a base de conhecimento (Operações sobre uma KB).

A dinâmica básica de funcionamento de GeneXus Server consiste em uma KB central em um servidor sendo administrado pela ferramenta, o desenvolvedor trabalha em um ambiente de desenvolvimento stand-alone, envia e recebe alterações de outros desenvolvedores.

GeneXus Server Conceito
Escrever software significa lotes de interação entre desenvolvedores. Interação, no entanto, não é permanente. Os desenvolvedores precisam “processar” cada recurso ou correção por conta própria, de alguma maneira isolada dos outros desenvolvedores, alheia às mudanças da Knowledge Base. Depois de terminado o processo os desenvolvedores comunicam e publicam suas alterações ou mudanças. O ciclo, em seguida, se repete.

Para implementar o ciclo acima, uma ferramenta deve fornecer um ambiente isolado de desenvolvimento e um serviço de comunicação. Isto é aonde GeneXus X Server (o servidor) vem a desempenhar:

Cada desenvolvedor trabalha com uma cópia de uma base de conhecimento (isolamento), que está ligada a uma cópia da KB centralizada e administrada pelo servidor (serviço de comunicação).

Figura 2 Modelo de Comunicação GeneXus X Server

Utilizando GeneXus X Server

Abaixo um resumo de utilização da ferramenta GeneXus X Server.

Configurando Um Novo Desenvolvedor
Para configurar um novo desenvolvedor é necessário iniciar o GeneXus na máquina de desenvolvimento e selecionar File/New Knowledge Base do menu de opção do servidor. Deverá ser selecionado o servidor e escolhido o endereço do GeneXus Server, e após isso, clicar no botão Connect. Após a conexão, uma lista de Knowledge Bases será exibida. Deve ser selecionada uma base de conhecimento e uma versão de desenvolvimento na KB. Depois, basta conferir o nome e local da KB nas opções de configuração e clicar no botão Create.

A base de conhecimento criada é uma exata cópia da KB do servidor. Após este procedimento, a conexão com o servidor é encerrada e o desenvolvedor estará pronto para trabalhar não conectado (off-line).

Enviando Alterações
Depois que um conjunto de mudanças está pronto, o desenvolvedor deve publicá-las. A tarefa de publicar alterações é chamada de Commit e exige que o servidor esteja ativo e acessível para o desenvolvedor. Ele deve selecionar Knowledge Manager/Team Developement do menu de opções para abrir o diálogo Team Developement.

Figura 4 Enviando Alterações

Deverá ser selecionado o botão de Pending Commits para carregar o conjunto de objetos que foram alterados desde a última operação de Commit local. Há uma opção onde pode ser inserido um comentário para o conjunto de mudanças. Basta clicar no botão Commit e pronto.

Recebendo Alterações De Outros Desenvolvedores
Para manter um desenvolvedor da Knowledge Base em dia com as mudanças feitas por outros desenvolvedores, é utilizada a opção knowledge Manager/Team Development do menu de opções para abrir o diálogo Team Development e o botão “Update from Server.

Conclusão

O GeneXus Server é um novo produto, está em versão beta e o seu desenvolvimento está em estágio avançado.

O seu objetivo é facilitar o trabalho em equipe. O conhecimento do negócio ficará centralizado e o time de desenvolvimento ficará constantemente integrado, mesmo os desenvolvedores estando geograficamente em pontos distantes.

Com GeneXus Server os avanços do projeto são monitorados mais facilmente.