Download - Entrega contínua e Automação
Entrega Contínua
e Automaçã
oTransição entre o
modelo cascata e a implantação de um modelo de Entrega
Contínua
Contextualização●Migração de Sistema Hospitalar (ERP) para uso em mais de 30
Hospitais Universitários (Oracle Forms/Reports → Software Livre)●Arquitetura baseada em tecnologias livres (Java / JBoss AS /
Postgres)●Necessidade de continuar funcionando em BD Oracle●Uso do SVN para controle de versão●Uso do Redmine para gestão do projeto2009 / 2010
- Arquitetura inicial JEE5- Equipe interna de desenvolvimento (~ 20 pessoas)
2011 / 2012- Equipe interna de desenvolvimento (mais de 60 pessoas)- Desenvolvimento de funcionalidades por times remotos- Liberações de “Pacotes de Melhorias” para a versão de produção
2013 / 2014- Migração da arquitetura para JEE7- Início de liberações de versão Beta- Início de trabalho com modelo de Fábrica de Software- Definição de novo modelo de liberação de versão - Entrega Contínua
2015 / 2016- Equipe de desenvolvimento interna e em modelo de Fábrica de Software (~100 pessoas)- Entregas contínuas de correções de incidentes, melhorias e desenvolvimento de novas funcionalidades.
Como tudo começou
Branch Contrucao = TrunkA cada Sprint o branch Qualidade era recriado e uma tag era gerada.
Versão 1.0
Versão 1.1, 1.2, 2.0
Como tudo começou
Somente Equipe de Operação tinha permissão de commit no branch FR (versão de produção).Branch RC crescia em número de commits mais que o branch FR (correção de incidentes e desenvolvimento de pequenas melhorias).Todos commits precisavam chegar ao branch Construcao para que nada fosse perdido na próxima versão do Sistema.
Como tudo começouCONS: Modelo exige retrabalho com merges. Novas versões do Sistema (major) necessitam bateria de Testes Regressionais em todas suas funcionalidades (sistema altamente acoplado).
PRÓS: Modelo funcional. Atende demandas emergenciais (incidentes). Permite adicionar novas funcionalidades antes da liberação de uma versão major do Sistema.
Passo a passo - 1º PassoPROBLEMA: São liberadas novas versões (minor) ou incidentes com alterações de BD.
BD de Teste, BD de Homologação, BD de Produção...
SOLUÇÃO: Versionar o BD (scripts DDL e DML)
Passo a passo - 2º PassoPROBLEMA: Erros de configuração nos servidores geram BUGs eventualmente.
SOLUÇÃO: Padronizar ambientes e colocá-los sob Gerência de Configuração utilizando uma ferramenta.
Realizando testes para melhorar as entregasInício do desenvolvimento usando o conceito de Feature Branches.Deploy de versões Beta.
Resumo deste modelo ...PRÓS: Possibilita entrega contínua de incidentes e pequenas melhorias. Se bem gerenciado, possibilita a entrega contínua de pequenas demandas (conjunto de melhorias).
CONS: Demanda uma bateria de testes regressionais para liberação de uma nova versão do Sistema (major). Ainda não possibilita a entrega contínua do desenvolvimento do Sistema.
Estudar um novo modelo.Investir na automação dos merges.
Adequar a solução a realidade do projeto.
Ruptura » Transição
Ruptura » Consolidação
Ruptura » Ferramentas
Hotfix » Merges
Hotfix » Recriação
Features » Fork
Features » Sincronização
Features » Reintegração
Entregas na Prática
Entregas na Prática
Entregas na Prática
Entregas na Prática
Entregas na Prática
Entregas na Prática
Desenvolvimento
Transição
Entregas na Prática
NúmerosDeploys (Produção)
- Todas segundas e quintas-feiras;- Média de 16 por mês ( + emergências).
Entregas (Novas Funcionalidades)
- 82 vagões já em produção (média de 7 por mês);- 36 vagões em andamento.
Automação- Mais de 30 VMs;- Mais de 100 builds diários;- 2 Jenkins;- Analistas podem disparar seus Jobs.
Qualidade- PMD;- Hooks do SVN (validações e restrições)- Testes Unitários (35%)- Testes Automatizados (WebDrive) (~100)- Checklist da Entrega;- Testes de Fronteiras.
Ferramentas de Apoio ao Desenvolvimento
Ferramentas de Apoio ao Desenvolvimento
Antes e DepoisModelo: Cascata Vários módulos; Meses de desenvolvimento; Alto volume de scripts de BD; Inúmeros menus e permissões novas; Difícil percepção do impacto de cada reintegração; Testes regressionais extensos; Insegurança.
Modelo: Entrega Contínua Uma fração do módulo (geralmente agregando valor ao usuário); Média de 2 meses de desenvolvimento por funcionalidade; Menor volume de scripts de BD; Impacto conhecido; Segurança na entrega; Rollback facilitado.
Dificuldades Encontradas● Cultura da Organização;
● Grande demanda;
● Sincronização entre branches;
● Dependência nas Entregas
Dúvidas ou
SugestõesEverton Schneider <
Matheus Cruz <[email protected]>
Renato Malvezzi <[email protected]>