Acelerando a entrega de software com as ferramentas de desenvolvimento da AWS
•Als PPTX, PDF herunterladen•
0 gefällt mir•981 views
A era dos ciclos anuais e semestrais de entrega de software está ficando para trás. Empresas líderes em seu segmento de mercado entregam software de alta qualidade em ciclos de poucos dias, em alguns casos, de poucas horas. Nesta sessão, iremos apresentar como você pode iniciar sua jornada para DevOps compartilhando boas práticas e ferramentas utilizadas pelos times de ‘duas pizzas’ da Amazon. Vamos mostrar como você pode acelerar sua produtividade implementando fluxos de integração e entrega contínua. E iremos introduzir os serviços que a AWS desenvolveu inspirados nas ferramentas e práticas internas da Amazon: AWS CodeCommit, AWS CodeBuild, AWS CodePipeline e AWS CodeDeploy. https://aws.amazon.com/pt/products/developer-tools/
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Acelerando a entrega de software com as ferramentas de desenvolvimento da AWS
Ähnlich wie Acelerando a entrega de software com as ferramentas de desenvolvimento da AWS (20)
Mehr von Amazon Web Services LATAM
Mehr von Amazon Web Services LATAM (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (6)
Acelerando a entrega de software com as ferramentas de desenvolvimento da AWS
- 1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Glauber Gallego, Arquiteto de Soluções 22/06/2017 Acelerando a entrega de software com as ferramentas de desenvolvimento da AWS
- 3. O que vamos ver nessa sessão? O que é DevOps? DevOps na Amazon AWS Code { Commit | Build | Pipeline | Deploy } Demo! AWS Code { Star }
- 4. Software em 2017 … velocidade importa
- 5. E o que DevOps tem a ver com isso? 30xmais deploys intervalo entre deploys 200xmenor 60xmenos falhas recuperação 168xmais rápida (source: puppet labs 2015 State of Devops Report) https://puppetlabs.com/sites/default/files/2015-state-of-devops-report.pdf
- 6. Então… O que é DevOps? • Cultura • Práticas • Ferramentas
- 7. Cultura DevOps • Dev & Ops caminhando juntos • ”um só time” • Responsabilidade Compartilhada • ”código, script, docs, infra” • Sentimento de propriedade • ”o PRD também é meu" • Visibilidade e comunicação • ”feedback contínuo de todos para todos”
- 8. Práticas DevOps Microserviços: de monolito a serviços desacoplados e independentes.
- 9. Práticas DevOps Integração Contínua (CI) Entrega Contínua (CD’) Deployment Contínuo (CD’’)
- 10. Práticas DevOps Infra como Código: seus recursos AWS descritos como código fonte.
- 11. Práticas DevOps Log e Monitoramento Proativo: • Rastreie e analise métricas e registros de log • Saiba em tempo real a performance de sua aplicação e de sua infraestrutura
- 12. Confiabilidade Vantagens da prática DevOps Velocidade Escala Entrega RápidaColaboração Segurança
- 13. Como era o desenvolvimento de software na Amazon… https://secure.flickr.com/photos/pixelthing/15806918992/
- 14. 2001 Transformação na Amazon: 2001-2009 2009 App monolítica + times em ’silos’ Microserviços + 2 ”pizza teams”
- 15. Com essa transformação passamos a entregar software muito mais rápido. Mas sentíamos que ainda faltava algo…
- 16. Em 2009, fizemos um estudo para encontrar ineficiências no processo.
- 17. Na maior parte do tempo estávamos esperando... …Codi ficar …Empa cotar …Deploy p/ QA Deploy p/PRD
- 18. Na maior parte do tempo estávamos esperando… …Codi ficar …Empa cotar …Deploy p/ QA Deploy p/PRD Mins Dias Mins Dias Mins Dias Mins
- 19. …Codi ficar …Empa cotar …Deploy p/ QA Deploy p/PRD Na maior parte do tempo estávamos esperando… Semanas Mins Dias Mins Dias Mins Dias Mins
- 20. …Codi ficar …Empa cotar …Deploy p/ QA Deploy p/PRD Na maior parte do tempo estávamos esperando… Weeks Mins Days Mins Days Mins Days Mins
- 21. E assim construímos ferramentas para automatizar nosso processo de release https://secure.flickr.com/photos/lindseygee/5894617854/
- 22. Ações automatizadas e transições: do check-in a produção Benefícios: • + rápido • + seguro • simplificação e padronização • visibilidade do processo Pipelines
- 23. Essa abordagem funcionou muito bem. Em 2014: • milhares de times de serviço • orientação a microserviços • prática de entrega contínua • ambientes diversos (staging, beta, produção) 50 milhões de deploys
- 24. E continua funcionando. Anualmente, realizamos uma pesquisa na Amazon com todos os nossos desenvolvedores. Em 2014 encontramos a ferramenta que podia ser correlacionada estatisticamente com a felicidade dos desenvolvedores: Nosso serviço de pipelines! Entrega contínua == desenvolvedores felizes
- 26. • Integrado • De Carga • De Interface • De Penetração Fases de um processo de release Fonte Build Teste Produção • Código Fonte (.php, .js, .java) • Revisão de código • Compilação • Teste Unitário • Métricas • Criação de imagens • Entrega para produção
- 27. Níveis de um processo de release Fonte Build Teste Produção Integração Contínua Entrega Contínua Deploy Contínuo
- 28. AWS CodePipeline AWS CodeCommit AWS CodeBuildAWS CodeDeploy AWS Code*
- 29. AWS Code* Fonte Build Teste Produção Release de Software:
- 30. AWS Code* Fonte Build Teste Produção Release de Software: AWS CodeCommit
- 31. AWS Code* Fonte Build Teste Produção Release de Software: AWS CodeBuild
- 32. AWS Code* Fonte Build Teste Produção Release de Software: Ferramentas de Parceiros
- 33. AWS Code* Fonte Build Teste Produção Release de Software: AWS CodeDeploy
- 34. AWS Code* Fonte Build Teste Produção Release de Software: EC2 On-Prem AWS CodeDeploy
- 35. AWS Code* Fonte Build Teste Produção Release de Software: AWS CodePipeline
- 36. AWS Code* Fonte Build Teste Produção Ferramentas de Parceiros Release de Software: AWS CodeCommit AWS CodeBuild AWS CodeDeploy AWS CodePipeline
- 37. Compile, Empacote e Teste sua aplicação https://secure.flickr.com/photos/spenceyc/7481166880
- 38. Serviço gerenciado para compilar, testar e empacotar software Processa builds em paralelo e escala automaticamente Crie ambientes customizados de build a partir de suas imagens Docker Pagamento por minuto Integrações com CodePipeline e Jenkins AWS CodeBuild
- 39. Como o CodeBuild funciona? 1. Obtém código fonte 2. Executa os comandos definidos no buildspec (containers Docker criados a cada build) 3. Envia saída em tempo real para o CloudWatch Logs 4. Submete o artefato gerado para um bucket do S3
- 40. buildspec.yml version: 0.1 environment_variables: plaintext: JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64" phases: install: commands: - apt-get update -y - apt-get install -y maven pre_build: commands: - echo Nothing to do in the pre_build phase... build: commands: - echo Build started on `date` - mvn install post_build: commands: - echo Build completed on `date` artifacts: type: zip files: - target/messageUtil-1.0.jar discard-paths: yes
- 41. buildspec.yml version: 0.1 environment_variables: plaintext: JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64" phases: install: commands: - apt-get update -y - apt-get install -y maven pre_build: commands: - echo Nothing to do in the pre_build phase... build: commands: - echo Build started on `date` - mvn install post_build: commands: - echo Build completed on `date` artifacts: type: zip files: - target/messageUtil-1.0.jar discard-paths: yes • Variáveis de ambiente • Fases de um processo de build: • Instale pacotes • Configure o ambiente • Verifique/Valide sintaxe • Compile seu código • Teste sua aplicação • Envie imagens docker para um repositório • Armazene artefatos no S3
- 42. 70% 20% 10%UI Service Unit Como distribuir meus testes?
- 43. Ferramentas de parceiros AWS CodeBuild BuildTest Como distribuir meus testes?
- 44. Faça deploy de suas aplicações https://secure.flickr.com/photos/simononly/15386966677
- 45. Automatize o deploy para qualquer servidor, mesmo on-premises Instale e/ou atualize suas aplicações Evite downtime durante deploys Rollback automático em caso de falha Faça o deploy de qualquer tecnologia, linguagem ou sistema operacional AWS CodeDeploy
- 46. appspec.yml version: 0.0 os: linux files: - source: / destination: /var/www/html permissions: - object: /var/www/html pattern: “*.html” owner: root group: root mode: 755 hooks: ApplicationStop: - location: scripts/deregister_from_elb.sh BeforeInstall: - location: scripts/install_dependencies.sh ApplicationStart: - location: scripts/start_httpd.sh ValidateService: - location: scripts/test_site.sh - location: scripts/register_with_elb.sh
- 47. appspec.yml version: 0.0 os: linux files: - source: / destination: /var/www/html permissions: - object: /var/www/html pattern: “*.html” owner: root group: root mode: 755 hooks: ApplicationStop: - location: scripts/deregister_from_elb.sh BeforeInstall: - location: scripts/install_dependencies.sh ApplicationStart: - location: scripts/start_httpd.sh ValidateService: - location: scripts/test_site.sh - location: scripts/register_with_elb.sh • (de)registre instâncias no ELB • Instale dependências • Inicie apache httpd • Verifique sucesso do deploy • Copie artefatos e arquivos de configuração para o destino • Defina o permissionamento de arquivos e diretórios
- 48. v2 v2 v2 v2 v2 v2 um por vez metade por vez todos de uma vez v2 v2 v2 v1 v1 v1 v2 v1 v1 v1 v1 v1 Agent Agent Deployment group: DEV OU Deployment group: PRD Agent AgentAgent Agent Agent Agent Escolha velocidade e agrupamento
- 49. Orquestre os passos de release com um pipeline https://www.flickr.com/photos/seattlemunicipalarchives/12504672623/
- 50. Serviço gerenciado para integração entrega deploy contínuo Modele visualmente seu processo de release Build, teste e faca deploy de seu código sempre que houver uma mudança Múltiplas integrações com ferramentas de parceiros AWS CodePipeline
- 53. Build CodeBuild AWS CodeBuild NotifyDevelopers Lambda TestAPI Runscope Ações Sequenciais Deploy JavaApp Elastic Beanstalk Source Source GitHub CodePipeline Aplicação
- 54. Build CodeBuild AWS CodeBuild Staging-Deploy JavaApp Elastic Beanstalk Prod-Deploy JavaApp Elastic Beanstalk QATeamReview Manual Approval Aprovação Manual Review CodePipeline Aplicação
- 55. Controle de código fonte GIT seguro, escalável e gerenciado Ferramental git padrão Durabilidade, disponibilidade e escalabilidade do Amazon S3 Dados criptografados em descanso com chaves fornecidas pelo cliente Sem limites de repositório Web-hooks através de ações com SNS/Lambda AWS CodeCommit
- 56. $ git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/aws-cli Cloning into 'aws-cli'... Receiving objects: 100% (16032/16032), 5.55 MiB | 1.25 MiB/s, done. Resolving deltas: 100% (9900/9900), done. Checking connectivity... done. $ nano README.rst $ git commit -am 'updated README' [master 4fa0318] updated README 1 file changed, 1 insertion(+) $ git push Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 297 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: To https://git-codecommit.us-east-1.amazonaws.com/v1/repos/aws-cli 4dacd6d..4fa0318 master -> master Mesmo git que você já conhece
- 57. Precificação CodeCommit $1 por usuário ativo por mês (primeiros 5 usuários grátis) CodePipeline $1 por pipeline ativo por mês (1 grátis) CodeDeploy Grátis para deploy em Amazon EC2 $0.02 por atualização de servidores on-premisse CodeBuild Compute Instance Type Memory(GB) vCPU Price per build minute ($) Small 3 2 0.005 Medium 7 4 0.010 Large 15 8 0.020
- 58. DEMO!
- 59. Demo: 1. Clone um repositório github.com/awslabs/aws-codedeploy-sample-tomcat 2. Crie um buildspec.yml 3. Crie um pipeline com os estágios Source e Build 4. Execute um Build 5. Adicione um estágio de deploy 6. Execute o pipeline
- 60. Demo: 1. Clone um repositório github.com/awslabs/aws-codedeploy-sample-tomcat 2. Crie um buildspec.yml 3. Crie um pipeline com os estágios Source e Build 4. Execute um Build 5. Adicione um estágio de deploy 6. Execute o pipeline
- 61. Demo: 1. Clone um repositório github.com/awslabs/aws-codedeploy-sample-tomcat 2. Crie um buildspec.yml 3. Crie um pipeline com os estágios Source e Build 4. Execute um Build 5. Adicione um estágio de deploy 6. Execute o pipeline
- 62. AWS CodeStar Comece a desenvolver em minutos Integre e colabore com seu time com segurança Gerencie a entrega de software Escolha templates e aceleradores NEW!NEW!
- 65. AWS DevOps Blog
- 66. Obrigado!
- 67. Ainda não tem o App oficial do AWS Summit São Paulo? http://amzn.to/2rOcsVy Não deixe de avaliar as sessões no app!
Hinweis der Redaktion
- https://secure.flickr.com/photos/mgifford/4525333972
- - this talk is broken into 2 sections - first, I'll start with the backstory about Amazon's own DevOps transformation, and the changes that we made to become more agile with our product delivery after covering this history, we're going to switch back to the present - I'm going to introduce 3 new AWS services that give you the same type of tools that we use internally at Amazon - You should walk away with a high level understanding of the different parts involved with a DevOps transformation, and an idea of how you could use our AWS Code services in your own DevOps processes
- DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.
- combination of microservices and increased release frequency more deployments and operational challenges Need ways to release software safely and reliably
- Treat infrastructure like you treat application code Innovations of the cloud – you can treat your entire infrastructure like code. You can access it programmatically using APIs We have a service that lets you use templates – declare the aws resources you want provisioned and how you want them provisioned Then you can check these templates into github and version control them You can easily replicate environments and share them with others You save time
- Monitor logs and metrics to improve application performance and infrastructure performance When trying to move quickly, you need to understand how changes are impacting your performance Services need to be on 24/7, so real time monitoring and analysis becomes rly important You can set automation (alerts, automatic changes, etc.)
- Teams work more efficiently and effectively, more nimble and agile Using automation to work efficiently and release software more rapidly You bake reliability and security into your automated practices to ensure your service is always running and infrastructure is in compliance When you’re growing quickly and moving fast, you need IaC to help you manage your infrastructure at scale. Repeatable processes Ultimately helps your organization increase its speed and velocity. The end goal is to innovate for your customers faster and become a better business
- https://secure.flickr.com/photos/pixelthing/15806918992/
- So we conducted a study. “Understanding Amazon’s Software Development Process Through Data” in 2009 by John Rauser We wanted to find out how long it takes to go from code check-in through to code being available in production. This included the time it took to build, test and deploy our software. We learned that this was taking a long time. In the order of weeks. And we didn’t want it take weeks to get a code change out to production.
- What we did discover was our processes had lot of human, manual work in them which were taking most of the time. Developers would use tickets or emails to track their release process. Developers would ticket or email other developers to run a build at which point a bunch of requests would batch up before being run. Once the build was done, new tickets were cut to deploy their software. Those requests may also batch up, increasing the time it took for a change to reach production.
- What we did discover was our processes had lot of human, manual work in them which were taking most of the time. Developers would use tickets or emails to track their release process. Developers would ticket or email other developers to run a build at which point a bunch of requests would batch up before being run. Once the build was done, new tickets were cut to deploy their software. Those requests may also batch up, increasing the time it took for a change to reach production.
- This was the problem we needed to solve. We needed to automate the production line of developer work so that humans were not longer causing developers to wait, when that work could be automated away.
- This was the problem we needed to solve. We needed to automate the production line of developer work so that humans were not longer causing developers to wait, when that work could be automated away.
- https://secure.flickr.com/photos/lindseygee/5894617854/
- https://www.flickr.com/photos/stevendepolo/5749192025/ - after we tell customers the story of our DevOps transformation, they typically ask us how they can do the same - I'm not going to over-simplify this, because it is a very complex answer - this can involve organizational changes, cultural changes, and process changes - plus there's no one right answer for these - every company is going to tweak their approach to optimize for their own environment - but there is one standard thing that every DevOps transformation needs, and that's an efficient and reliable continuous delivery pipeline - that's the focus for the rest of this talk
- I want to take a moment to talk about different release processes. Each team’s release process takes a different shape to accommodate the needs of each team. Nearly all release processes can be simplified down to four stages – source, build, test and production. Each phase of the process provides increase confidence that the code being made available to customers will work in the way that was intended. During the source phase, developers check changes into a source code repository. Many teams require peer feedback on code changes before shipping code into production. Some teams use code reviews to provide peer feedback on the quality of code change. Others use pair programming as a way to provide real time peer feedback. During the Build phase an application’s source code is built and the quality of the code is tested on the build machine. The most common type of quality check are automated tests that do not require a server in order to execute and can be initiated from a test harness. Some teams extend their quality tests to include code metrics and style checks. There is an opportunity for automation any time a human is needed to make a decision on the code. The goal of the test phase is to perform tests that cannot be done on during the build phase and require the software to be deployed to a production like stages. Often these tests include testing integration with other live systems, load testing, UI testing and penetration testing. At Amazon we have many different pre-production stages we deploy to. A common pattern is for engineers to deploy builds to a personal development stage where an engineer can poke and prod their software running in a mini prod like stage to check that their automated tests are working correctly. Teams deploy to pre-production stages where their application interacts with other systems to ensure that the newly changed software work in an integrated environment. Finally code gets deployed to production. Different teams have different deployment strategies though we all share a goal of reducing risk when deploying new changes and minimizing the impact if a bad change does get out to production. Each of these steps can be automated without the entire release process being automated. There are several levels of release automation that I’ll step through.
- Continuous Integration Continuous Integration is the practice of checking in your code to the continuously and verifying each change with an automated build and test process. Over the past 10 years Continuous Integration has gained popularity in the software community. In the past developers were working in isolation for an extended period of time and only attempting to merge their changes into the mainline of their code once their feature was completed. Batching up changes to merge back into the mainline made not only merging the business logic hard, but it also made merging the test logic difficult. Continuous Integration practices have made teams more productive and allowed them to develop new features faster. Continuous Integration requires teams to write automated tests which, as we learned, improve the quality of the software being released and reduce the time it takes to validate that the new version of the software is good. There are different definitions of Continuous Integration, but the one we hear from our customers is that CI stops at the build stage, so I’m going to use that definition. Continuous Delivery Continuous Delivery extends Continuous Integration to include testing out to production-like stages and running verification testing against those deployments. Continuous Delivery may extend all the way to a production deployment, but they have some form of manual intervention between a code check-in and when that code is available for customers to use. Continuous Delivery is a big step forward over Continuous Integration allowing teams to be gain a greater level of certainty that their software will work in production. Continuous Deployment Continuous Deployment extends continuous delivery and is the automated release of software to customers from check in through to production without human intervention. Many of the teams at Amazon have reached a state of continuous deployment. Continuous Deployment reduces the time for your customers to get value from the code your team has just written, with the team getting faster feedback on the changes you’ve made. This fast customer feedback loop allow you to iterate quickly, allowing you to deliver more valuable software to your customers, quicker.
- https://secure.flickr.com/photos/spenceyc/7481166880
- The effort you put into the testing triangle should not be evenly distributed! Many experts in the industry recommend a 70,20,10 mix. (will need sources)
- The effort you put into the testing triangle should not be evenly distributed! Many experts in the industry recommend a 70,20,10 mix. (will need sources)
- https://secure.flickr.com/photos/simononly/15386966677
- https://www.flickr.com/photos/seattlemunicipalarchives/12504672623/
- Let’s take a look at an example Pipeline. I’ve created a simple 3 stage Pipeline to talk though my example. Source actions are special actions. They continuously poll the source providers, such as GitHub and S3, in order to detect changes. Once a change is detected, the new pipeline run is created and the new pipeline begins its run. The source actions retrieve a copy of the source information and place it into a customer owned S3 bucket. Once the source action is completed, the Source stage is marked as successful and we transition to the Build stage. In the Build Stage we have one action, Jenkins. Jenkins was integrated into CodePipeline as a CustomAction and has the same lifecycle as all custom actions. Talk through interaction Once the build action is completed, the Build stage is marked as successful and we transition to the Deploy stage The Deploy stage contains one action, an AWS Elastic Beanstalk deployment action. The Beanstalk action retrieves the build artifact from the customer’s S3 bucket and deploys it to the Elastic Beanstalk web container.
- Let’s take a look at an example Pipeline. I’ve created a simple 3 stage Pipeline to talk though my example. Source actions are special actions. They continuously poll the source providers, such as GitHub and S3, in order to detect changes. Once a change is detected, the new pipeline run is created and the new pipeline begins its run. The source actions retrieve a copy of the source information and place it into a customer owned S3 bucket. Once the source action is completed, the Source stage is marked as successful and we transition to the Build stage. In the Build Stage we have one action, Jenkins. Jenkins was integrated into CodePipeline as a CustomAction and has the same lifecycle as all custom actions. Talk through interaction Once the build action is completed, the Build stage is marked as successful and we transition to the Deploy stage The Deploy stage contains one action, an AWS Elastic Beanstalk deployment action. The Beanstalk action retrieves the build artifact from the customer’s S3 bucket and deploys it to the Elastic Beanstalk web container.
- Let’s take a look at an example Pipeline. I’ve created a simple 3 stage Pipeline to talk though my example. Source actions are special actions. They continuously poll the source providers, such as GitHub and S3, in order to detect changes. Once a change is detected, the new pipeline run is created and the new pipeline begins its run. The source actions retrieve a copy of the source information and place it into a customer owned S3 bucket. Once the source action is completed, the Source stage is marked as successful and we transition to the Build stage. In the Build Stage we have one action, Jenkins. Jenkins was integrated into CodePipeline as a CustomAction and has the same lifecycle as all custom actions. Talk through interaction Once the build action is completed, the Build stage is marked as successful and we transition to the Deploy stage The Deploy stage contains one action, an AWS Elastic Beanstalk deployment action. The Beanstalk action retrieves the build artifact from the customer’s S3 bucket and deploys it to the Elastic Beanstalk web container.
- Let’s take a look at an example Pipeline. I’ve created a simple 3 stage Pipeline to talk though my example. Source actions are special actions. They continuously poll the source providers, such as GitHub and S3, in order to detect changes. Once a change is detected, the new pipeline run is created and the new pipeline begins its run. The source actions retrieve a copy of the source information and place it into a customer owned S3 bucket. Once the source action is completed, the Source stage is marked as successful and we transition to the Build stage. In the Build Stage we have one action, Jenkins. Jenkins was integrated into CodePipeline as a CustomAction and has the same lifecycle as all custom actions. Talk through interaction Once the build action is completed, the Build stage is marked as successful and we transition to the Deploy stage The Deploy stage contains one action, an AWS Elastic Beanstalk deployment action. The Beanstalk action retrieves the build artifact from the customer’s S3 bucket and deploys it to the Elastic Beanstalk web container.