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






Desenvolvimento

Transição


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 <

[email protected]>

Matheus Cruz <[email protected]>

Renato Malvezzi <[email protected]>

mailto:[email protected]

