Baixar para ler offline
Carregado porAndré Minelli
Deploy Automatizado usando Octopus
O documento discute os benefícios do deploy automatizado usando a ferramenta Octopus. Ele explica que o deploy automatizado reduz riscos, erros humanos e dependência de especialistas, permitindo entregar valor aos clientes mais rápido através de frequência maior de deployments. Também aborda como configurar ambientes, projetos, variáveis e pipelines complexos no Octopus.
Deploy Automatizado usando Octopus
- 1.
- 2.
- 3. Deploy Automatizado Por que? ◦Fimde roteiro de instalação manual
- 4. Deploy Automatizado Por que? ◦Fimde roteiro de instalação manual ◦Reduz dependência de especialistas e/ou ‘super usuários’
- 5. Deploy Automatizado Por que? ◦Fimde roteiro de instalação manual ◦Reduz dependência de especialistas e/ou ‘super usuários’ ◦Reduz chance de erros humanos
- 6. Deploy Automatizado Por que? ◦Fimde roteiro de instalação manual ◦Reduz dependência de especialistas e/ou ‘super usuários’ ◦Reduz chance de erros humanos ◦Mais velocidade
- 7. Deploy Automatizado Por que? ◦Fimde roteiro de instalação manual ◦Reduz dependência de especialistas e/ou ‘super usuários’ ◦Reduz chance de erros humanos ◦Mais velocidade
- 8.
- 9. Deploy Automatizado Objetivo Principal: Provervalor mais rápido para os clientes!
- 10.
- 11. Deploy Automatizado COMO? Reduzindo orisco de instalações
- 12. Deploy Automatizado ◦Se orisco é baixo, o medo é reduzido
- 13. Deploy Automatizado ◦Se orisco é baixo, o medo é reduzido ◦Se o medo é reduzido, a frequencia pode aumentar
- 14. Deploy Automatizado ◦Se orisco é baixo, o medo é reduzido ◦Se o medo é reduzido, a frequencia pode aumentar ◦Se a frequencia aumenta, mais valor (features e correções) podem ser entregues mais rapidamente
- 15. Deploy Automatizado ◦Se orisco é baixo, o medo é reduzido ◦Se o medo é reduzido, a frequencia pode aumentar ◦Se a frequencia aumenta, mais valor (features e correções) podem ser entregues mais rapidamente ◦Se valor pode ser entregue mais rapidamente, meus clientes ficarão felizes mais rápido
- 16. Deploy Automatizado ◦Se orisco é baixo, o medo é reduzido ◦Se o medo é reduzido, a frequencia pode aumentar ◦Se a frequencia aumenta, mais valor (features e correções) podem ser entregues mais rapidamente ◦Se valor pode ser entregue mais rapidamente, meus clientes ficarão felizes mais rápido ◦Clientes felizes significa que o negócio continuará crescendo
- 17. Deploy Automatizado Intimamente ligadoà Agile / Lean: Somente quando o usuário usa o produto teremos seu feedback!
- 18.
- 19.
- 20. Deploy Automatizado Benefícios adicionais: ◦Rollbacksimplificado ◦Ambientes adicionais (homologação, staging, etc) facilmente criados
- 21. Deploy Automatizado Benefícios adicionais: ◦Rollbacksimplificado ◦Ambientes adicionais (homologação, staging, etc) facilmente criados ◦Contribui para Disaster Recovery
- 22. Deploy Automatizado Benefícios adicionais: ◦Rollbacksimplificado ◦Ambientes adicionais (homologação, staging, etc) facilmente criados ◦Contribui para Disaster Recovery ◦Registro das mudanças aplicadas
- 23. Deploy Automatizado ◦Passo crucialpara Continuous Delivery ◦Capacidade de fazer deploy a cada mudança ◦Quais mudanças entrarão em produção é uma escolha ◦Pré-requisito para Continous Deployment ◦Toda mudança é automaticamente publicada em produção
- 24. Deploy Automatizado Necessário COMPROMISSOdo time: Nenhuma alteração do servidor deve ser feita manualmente!
- 25. Octopus Deploy Servidor deautomated deployment Focado em (mas não limitado a): ◦ .NET ◦ Windows Servidor ◦ Gerencia configurações ◦ Registra histórico e logs ◦ Repositório de packages Tentáculos ◦ Executam as etapas do processo de deploy ◦ Windows Service em cada servidor (target)
- 26. Octopus Deploy xTeamCity Octopus complementa continuous building ◦TeamCity (ou outro Build Server): ◦compila, testa e analisa código ◦produz artefatos aprovados ◦Octopus ◦Distribui e instala artefatos ◦Aplica configurações específicas do ambiente
- 28. Octopus Deploy –Boas práticas
- 29. Octopus Deploy –Boas práticas ◦Artefato é construído uma única vez ◦Todos os ambientes recebem o mesmo binário
- 30. Octopus Deploy –Boas práticas ◦Artefato é construído uma única vez ◦Todos os ambientes recebem o mesmo binário ◦Valores de configuração não fazem parte do repositório ◦Devem ser definidos em deploy time
- 31. Octopus Deploy –Boas práticas ◦Artefato é construído uma única vez e empacotado ◦Todos os ambientes recebem o mesmo binário ◦Valores de configuração não fazem parte do repositório ◦Devem ser definidos em deploy time ◦Processo de deploy deve ser igual (ou MUITO parecido) em todos os ambientes
- 32. Octopus Deploy –Integração TeamCity ◦.Net ◦ Gere Nuget packages ◦ Install-Package OctoPack ◦No build step da solution: ◦Marque “Run OctoPack” ◦OctoPack package version: %build.number% ◦Recomendado: ◦Em Build Feature: ◦AssemblyInfo patcher (com mesmo %build.number%)
- 33. Octopus Deploy –Integração TeamCity ◦Outros projetos: use artefatos zipados ◦Em General Settings, configure Artifact paths ◦Ex: dist => %PackageName%.zip ◦Salve zip no repositório do Octopus ◦Build step OctopusDeploy: Push packages ◦Utilize parâmetro global OctopusUrl ◦ Crie sua API Key no Profile do usuário do Octopus
- 34. Octopus Deploy –Integração TeamCity ◦Crie release no Octopus ◦ Build step “OctopusDeploy: Create Release” ◦ Utilize parâmetro global OctopusUrl ◦ Additional command line arguments --Packageversion=%build.number% ◦Recomendado ◦ Criar release notes a partir dos commits ou do backlog ◦ Adicione antes o build step “ReleaseNotesFromVso” ◦ Adicione nos argumentos da linha de comando para criar a release -- ReleaseNotesFile="%system.teamcity.build.tempDir%relea senotesfile_%teamcity.build.id%_%build.number%.txt“
- 35. Octopus Deploy –Configuração Básica Ambientes ◦Máquinas ◦Papéis Projetos ◦Parte de Grupo de Projetos ◦Lifecycle ◦Process ◦Variables
- 36.
- 37. Octopus Deploy –Configurações de ambientes ◦Tentáculo – utilize ‘Listening Tentacle’ ◦Roles – baseado em função ◦ Não é ambiente ◦ Não é versão de S.O. ◦Mesma máquina pode fazer parte de mais de um ambiente
- 38. Octopus Deploy –Configurações de projetos
- 39. Octopus Deploy –Configurações de projetos Dica: ◦Processo em 3 ‘etapas’:
- 40. Octopus Deploy –Configurações de projetos Dica: ◦Processo em 3 ‘etapas’: 1. Configurar/verificar ambiente/SO ◦ Windows Features, Firewall, Certificados, etc ◦ Obs: trabalho para Chef / Puppet / etc
- 41. Octopus Deploy –Configurações de projetos Dica: ◦Processo em 3 ‘etapas’: 1. Configurar/verificar ambiente/SO ◦ Windows Features, Firewall, Certificados, etc ◦ Obs: trabalho para Chef / Puppet / etc 2. Instalação propriamente dita ◦ Baixar package e aplicar configurações ◦ Configurar serviços, sites, tarefas agendadas, etc
- 42. Octopus Deploy –Configurações de projetos Dica: ◦Processo em 3 ‘etapas’: 1. Configurar/verificar ambiente/SO ◦ Windows Features, Firewall, Certificados, etc ◦ Obs: trabalho para Chef / Puppet / etc 2. Instalação propriamente dita ◦ Baixar package e aplicar configurações ◦ Configurar serviços, sites, tarefas agendadas, etc 3. Testes / notificação ◦ Scripts com smoke tests ◦ Notificações – email, Slack, Webhook, etc
- 43. Octopus Deploy –Configurações de projetos ◦Steps do processo podem ter condições: ◦Papeis (Roles) ◦Ambientes (Environment) ◦Selecionam em quais targets o step executará
- 44. Octopus Deploy –Configurações de projetos Package deploys: ◦Usado para Windows Services e IIS Apps ◦Tipos de packages: ◦Nuget (repositório interno ou externo) ◦Zip, Tar, etc (repositório interno) ◦TeamCity funciona como repositório externo
- 45. Octopus Deploy –Configurações de projetos ◦Utilize variáveis para alterar valores de configurações ◦Podem ser aplicadas por role, environment, target ou mesmo step ◦Necessário habilitar a feature “Configuration variables” ◦Utilize transformações para demais alterações ◦Exemplo: adicionar ou remover elementos nos arquivos .config ◦Necessário habilitar a feature “Configuration transforms”
- 46. Octopus Deploy –Configurações de projetos Importante: ◦Steps executam em sequência ◦Ação(ões) do step executa(m) em paralelo em cada target ◦Variáveis devem existir nos arquivos para serem substituídas ◦Conteúdo das váriáveis e steps do processo são salvos para cada release gerada ◦ Variáveis podem ser atualizadas
- 47. Octopus Deploy –Saindo do básico ◦Adicione process steps da Community Library ◦AWS ◦Azure ◦File System, etc ◦Custom scripts (powershell, C#) nos packages ou steps ◦ PreDeploy ◦ Deploy ◦ PostDeploy ◦ DeployFailed
- 48. Octopus Deploy –Saindo do básico ◦Crie Channels para diferentes lifecycles ◦Hotfix -> direto para produção ◦Canal por componente (e um canal para todos juntos) ◦TeamCity: informe o channel da release no step “OctopusDeploy: Create Release”
- 49. Octopus Deploy –Saindo do básico ◦Defina pipelines mais complexos ◦Rolling ◦Canary ◦Blue-green
- 50.
- 51.
- 52.
- 53.
- 54. Octopus Deploy – Blue/ Green
- 55. Referências e materialadicional Understanding DevOps – Part 6: Continuous Deployment vs Continuous Delivery ◦ https://sdarchitect.wordpress.com/2013/10/16/understanding-devops-part-6- continuous-deployment/ Continuous Delivery Vs. Continuous Deployment: What's the Diff? ◦ https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what- s-diff The Benefits of Deployment Automation ◦ http://download.octopusdeploy.com/files/whitepaper-automated-deployment- octopus-deploy.pdf
- 56. Referências e materialadicional Octopus Deploy Documentation ◦ http://docs.octopusdeploy.com/display/OD/Getting+started Octopus Deploy Patterns ◦ http://docs.octopusdeploy.com/display/OD/Patterns Enable or Disable Windows Features using DISM ◦ https://technet.microsoft.com/en- us/library/hh824822.aspx?f=255&MSPPError=-2147217396
Notas do Editor
- #4 Roteiro de instalação = documentação: ficam desatualizados rapidamente
- #5 Pegar as senhas corretas, verificar se tenho as permissões adequadas… Silos de conhecimento
- #6 Enganos = update sem where
- #7 Velocidade – principalmente quando vários servidores devem ser atualizados
- #8 Na verdade, tudo isto é consequencia: Automatização = eficiência ->
- #12 Risco baixo = estável, fácil, rápido, reproduzivel
- #18 Lean = Build (fast, cheap), Measure, Learn. Repeat!
- #22 Disaster Recovery -> a partir do repositorio de código (e nova infra condizente) é possivel reconstruir rapidamente o produto Obs: necessário um backup para retornar ao ponto anterior
- #23 Ambientes adicionais OU novos servidores!! Todos os componentes utilizados e como devem ser instalados estão ‘documentados’ Registro = o que, quem, quando, onde
- #24 Continous Deployment exige uma maturidade (do processo de testes pré-producao e de monitoramento pós producao) muito maior
- #25 Nem sempre é possível ou rapido: -pacotes sem instalação (crie um package para chocolatey) -configurações do Windows (verifique opções de linha de comando,powershell, registro) Pendencia: infraestrutura (HA, firewall, policies do Windows) Ferramentas como Chef e Puppet complementam a automatização
- #26 Não só Windows – deploy via ssh / sftp / mono Tentaculo = agente(s) nos servidores destino
- #27 Como comparei com o TC…
- #28 Package = nuget ou zip com a versão como sufixo
- #30 1-Diferença entre ambientes é apenas configuração! Nao há binario diferente por ambiente!
- #31 2-Se uma conf. ou ambiente alterar, basta fazer um redeploy de um binário ou alterar o processo
- #32 3-O processo de deploy deve ser repetivel e estavel. Quanto menos alterar entre ambiente, melhor testado será Abrindo parentheses e detalhando primeira boa prática: construir o artefato -> TeamCity
- #33 MAO na massa: mostrar solution TeamCity possui Nuget Server interno para packages gerados
- #34 Build step OctopusDeploy é wrapper sobre Octo.exe (ambos baixados no site do Octopus) Obs: Usuário da API Key deve ter permissão no projeto!!!
- #35 Obs: Usuário da API Key deve ter permissão no projeto!!! ReleaseNotesFromVSO: Commits devem ter #<id> da tarefa ou item do backlog Fim do parentheses – de volta ao Octopus!
- #36 Maquinas = devem ter o Tentáculo instalado Projeto = produto / plataforma / componente que será instalado Lifecycle = pipeline de ‘promoção’ de versões entre ambientes Process = passos para um deploy Variables = customização por ambiente / papel
- #37 Ver roteiro
- #38 Roles descrevendo ambiente ou s.o. são melhor tratados como ambientes mesmo
- #39 Voltar ao roteiro: (linha 20) mostrar library e criação de projetos
- #40 Mantra: automatizar tudo que for possível!!!
- #41 Configurar ambiente: steps “Windows – Ensure Features are installed” e “Chocolatey – Ensure installed” Testes – scripts em powershell ou C#
- #43 Testes – scripts em powershell ou C# Voltar para demo, criando processo para projeto demo
- #47 Obs: Snapshot das variáveis e processo são uma diferença crucial em relação ao Teamcity, onde os steps de build atuais são sempre executados (alias, por isso é recomendado salvar seu processo de build no repositorio de codigo tb) Dica para utilizar a ultima versao do processo: recriar release como um hotfix, mas usando a ultima versao dos packages
- #48 Exemplo: Deploy.ps1 para aplicar migrations
- #49 Channel pode ser especificado no step “OctopusDeploy: Create release” do Teamcity
- #50 -Rolling – deploy de X targets por vez (window size + child steps para gerencia L.B.) -Canary – 3 opções: manual (escolhendo targets); com manual intervention + duplicação dos passos; com multiplos ambientes -Blue-green – ambientes blue e green
- #51 Deploy de X targets por vez (window size + child steps para gerencia L.B.)
- #52 Deploy de X targets por vez (window size + child steps para gerencia L.B.)
- #53 3 opções: manual (escolhendo targets); com manual intervention + duplicação dos passos; com multiplos ambientes
- #54 3 opções: manual (escolhendo targets); com manual intervention + duplicação dos passos; com multiplos ambientes
- #55 ambientes blue e green