TDC2016SP - Trilha DevOps Java
2 gostaram277 visualizações
O documento discute como automatizar o processo de desenvolvimento de uma aplicação mesmo quando a empresa cliente não permite DevOps. Ele apresenta como a equipe automatizou o ambiente de desenvolvimento usando Docker para criar containers com o banco de dados e servidores de aplicação, e Jenkins para integração contínua. A automação reduziu problemas com VPNs e tempos de configuração, permitindo que outras aplicações do cliente também adotassem o Docker.
TDC2016SP - Trilha DevOps Java
- 1. Meu cliente não permite DevOps. E agora?
- 3. Cenário ideal • Builds automatizados; • Alta cobertura de testes; • Entrega ou deploy continuo; • Criação do ambiente automatizado;
- 4. Possíveis barreiras. • Infraestrutura; • Restrição de Segurança; • Processos / Politicas; • Implantação em terceiros; • Falta de interesse (ou falta de conhecimento);
- 5. O que pode ser automatizado? • Produção; • Homologação; • Desenvolvimento;
- 6. Nossas Barreiras... • Servidor interno; • Produção; • Homologação; • Restrições de segurança;
- 7. ... e nossa infra • Servidor Central • WebLogic; • Banco de Dados – Oracle; • Servidor Filial • Weblogic: • Fila de Sincronização; • Fila de tratamento de erros; • Banco de Dados – Mysql • 3 instâncias: Gravação, Leitura, Leitura – Espelho; • Com configurações específicas;
- 8. Problemas com desenvolvimento • Conexão com o cliente instável (VPN); • Banco de Dados concorrente; • Tempo para configuração de ambiente; • Manter histórico de atualizações do Banco de Dados;
- 9. Solução: • Docker • 2 Weblogic; • Oracle; • Mysql; • Flyway: • Banco Mysql (legado); • Banco Oracle;
- 10. O que foi automatizado: • Weblogic (central e filial) • Filas JMS; • DataSources; • Oracle • Migrations; • Mysql • Migrations (apenas tabelas relevantes); • Dados de teste; • Jenkins • Integração continua;
- 11. O que ganhamos? • Acabou problema com VPN; • Tempo de configuração de ambiente caiu; • Cliente adotou as migrations; • Configuração do Weblogic ficou documentada (Python); • Outras aplicações do mesmo cliente adotaram o Docker; • Cliente tem a infra configurada caso desejar adotar adotar;
- 12. Por que não Vagrant?
- 13. Próximos passos
- 14. Cenário • Equipe de TI e Devs isoladas; • Equipes aprendendo “por conta”; • Equipes com ambiente de dev nas nuvens; • Algumas equipes sem nenhum tipo de automatização; • Inclusive algumas equipes sem teste automatizado;
- 15. Mudança na equipe de Ops • Disseminar a cultura de DevOps • Construção de uma nuvem privada; • CloudStack + Chef; • Utilização de ambientes dev, hom e QA; • Aproximação dos Ops dos Devs; • Equipe de Ops “circulando” entre as equipes de dev; • Estreitar laços entre as equipes; • Devs aprender um pouco de ops;
- 16. Mudança na equipe de Devs • Equipe apoiando o monitoramento das aplicações; • Zabbix, NewRelic, etc... • Definição de um responsável por apoiar as equipes em automatização; • Disseminar conhecimento entre as equipes; • Automatizar tudo o que for possível; • Tornar as equipes responsáveis pelas suas automatizações; • Meta: 100% das equipes automatizadas;
- 17. Dicas Não apanhe como a gente apanhou...
- 18. Organização
- 19. Fragmentação Flyway • 1__estrutura_inicial.sql • 2__enderecos_funcionarios.sql • 3__financeiro.sql • 4__compras.sql
- 20. Fragmentação Flyway • 1_1_1__estrutura_funcionarios.sql • 1_1_2__dados_funcionarios.sql • 1_2_1__estrutura_funcionario_endereco.sql • 1_2_2__dados_funcionario_endereco.sql • 1_3_1__estrutura_financeiro_contas.sql • 1_3_2__dados_financeiro_contas.sql • 1_4_1__nova_coluna_cep_funcionario_endereco.sql • 1_4_2__dados_cep_funcionario_endereco.sql
- 21. Docker compose • Disponível no Windows a partir da versão 1.9.0-rc3 (30/10/2015); • Facilita levantar as maquinas em conjunto; • Antes o projeto usava um arquivo .sh;