Processo de release

O Gfacility opera num verdadeiro modelo Software as a Service (SaaS), o que significa que existe apenas uma versão unificada do nosso software para todos os utilizadores. Ao contrário de releases individuais por cliente, cada nova versão fica imediatamente em vigor para todos os clientes. Isto garante software estável, mantém todos os clientes atualizados e não exige esforço adicional para o release/atualização. Para gerir isto de forma eficiente, o Gfacility segue um processo de release composto por 3 fases.

Processo de release

A ilustração abaixo mostra o processo pelo qual passa cada funcionalidade.

Fase I - Planeamento e design

O nosso backlog é continuamente alimentado por sugestões internas de melhoria, pelo roadmap e por pedidos de clientes. De duas em duas semanas são selecionadas e planeadas funcionalidades, após o que se segue uma análise técnica (TA) e, eventualmente, uma proposta de design.

Fase II - Desenvolvimento e Garantia de Qualidade

Após o planeamento e design, cada funcionalidade é desenvolvida, com um lead time de pelo menos 4 semanas (2 sprints) até 12 semanas ou mais, dependendo da complexidade da funcionalidade a desenvolver. As funcionalidades desenvolvidas são implantadas no ambiente de Development, onde a nossa equipa de qualidade corre testes e regista defeitos.

Fase III - User Acceptance Test e Release em Produção

As funcionalidades no ambiente de Development são libertadas em pacote para o ambiente de UAT num ciclo padrão de 4 semanas. Os clientes têm 4 semanas para testar a nova release antes de ser implantada no ambiente de Produção. O feedback deve ser submetido o mais tardar 1 semana antes da release; depois disso não podemos garantir que ainda entre na próxima release. O feedback sobre o ambiente de UAT pode ser submetido pelos clientes no ambiente de suporte da Gfacility.

Em consequência de defeitos graves no ambiente de UAT, uma release pode ser adiada ou cancelada. Os clientes recebem aviso, no máximo, na última quarta-feira antes da release, se esta não avançar. Se a release decorrer conforme planeado, não será enviado aviso.

O planeamento de releases pode ser consultado aqui. As notas de versão para os ambientes de UAT e de Produção serão partilhadas todas as sextas-feiras antes da release.

Incidentes / BUGS

Os incidentes e bugs são tipicamente detetados e resolvidos no ambiente de UAT, mas pode acontecer que um bug surja ainda em produção. Para salvaguardar a estabilidade do software, os bugs são primeiro resolvidos no ambiente de UAT e depois implantados em produção na release seguinte. Apenas os bugs com impacto crítico, que tornam o trabalho impossível sem um workaround disponível, são resolvidos diretamente no ambiente de produção. Este processo visa minimizar os incidentes e manter um ambiente de software estável e fiável para os nossos utilizadores.

Pedidos de clientes

Os pedidos de clientes são importantes para a evolução contínua do nosso software e podem ser submetidos através do ambiente de suporte. De duas em duas semanas todos os pedidos são revistos e os próximos passos comunicados. Quando um pedido é aceite, é adicionado ao processo de release descrito acima.