DevOps@Scale [Portuguese]
•Transferir como PPTX, PDF•
0 gostou•61 visualizações
Com a adoção de princípios ágeis, os clientes se deparam com a necessidade de desenvolver, construir e implantar aplicações em larga escala. Junte-se a nós nesta sessão, focada em como usar os serviços da AWS para criar uma plataforma de DevOps para fornecer serviços de Integração contínua (CI) e entrega contínua (CD) que se adaptam à sua necessidade. Uma abordagem de DevOps corporativa é um ponto vital para a adoção de nuvem em escala e, portanto, analisaremos como o CI/CD pode acelerar sua adoção de forma integrada. Palestrante: Alex Coqueiro
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a DevOps@Scale [Portuguese]
Semelhante a DevOps@Scale [Portuguese] (20)
Mais de Amazon Web Services
Mais de Amazon Web Services (20)
DevOps@Scale [Portuguese]
- 1. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Alex Coqueiro Arquitetura de Soluções para Governo, Educação e Entidades sem fins lucrativos DevOps@Scale
- 3. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. EsperCodificação EsperBuild EsperDeploy em teste Deploy em Produção Estudo na Amazon em 2009 Minutos Dias Minutos Dias Minutos Dias Minutos Semanas
- 4. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. EsperCodificação EsperBuild EsperDeploy em teste Deploy em Produção Estudo na Amazon em 2009 Minutos Dias Minutos Dias Minutos Dias Minutos Semanas
- 5. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Processo de Desenvolvimento de Forma Ágil Business Case Requisitos Use Case Features Plano Goto market Negócios Design Codificar Refactor Testes Bug Fix Deploy Desenvolvedores Provisionar Configurar Orquestrar Deploy Reportar Monitorar Operações • Continuous Integration • Continuous Deployment • Continuous Delivery DevOps Agile Development • Desenvolvimento Iterativo • Scrum, Kanban • Sprints • Stories Agilidade de Negócio Agilidade de TI
- 6. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Impacto de Devops nas Empresas 5xRedução das métricas de falha 440xMais rápido para evoluir do commit até o deploy da aplicação 46xMaior frequencia com deployments 44%Mais tempo gasto com novas funcionalidades Source: Puppet 2017 State of DevOps Report
- 8. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. • Testes integrados • Testes de carga • Teste de Interface • Teste de Invasão Source Build Teste Deploy Operação Ciclo de Vida da Aplicação • Codificação • Check-in • Peer review • Compilação • Teste Unitários • Style checkers • Criar imagens (containers) • Promover ambientes • (Ex: Produção) • Monitoração
- 9. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Continuous Integration (CI) Continuous Delivery (CD) Continuous Deployment (CD) Source Build Teste Deploy Operação Ciclo de Vida da Aplicação
- 10. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Source Build Teste Deploy Operação AWS CodeBuild + Ferramentas externas AWS Cloud 9 AWS CodeCommit AWS Toolkit for Developers AWS CodeBuild Elastic BeansTalk AWS CodePipeline AWS CodeStar Amazon CloudWatch Ciclo de Vida da Aplicação
- 11. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Source Build Teste Deploy Operação AWS CodeBuild + Third Party AWS Cloud 9 AWS CodeCommit AWS Toolkit for Developers AWS CodeBuild Elastic BeansTalk AWS CodePipeline Amazon CloudWatch AWS CodeStar Ciclo de Vida da Aplicação
- 12. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Devops Corporativamente
- 13. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Ambiente de Produção Relatórios CodeCommit Commit Dev Acct Prod Acct Tools Acct Coordenação Build Artifacts Externamente Teste Ambiente de Testes Test Acct Relatórios 1 Lambda CodePipeline Amazon Inspector AWS Config CodeBuild 2 3 4 5 7 7 Deploy Elastic Beanstalk CloudFormation OpsWorks Jenkins Amazon ECS EB EC2 CodeBuild Jenkins Amazon Inspector AWS Config Amazon ECS EB EC2 6
- 15. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS DevOps Blog
- 16. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Muito Obrigado !!!
Notas do Editor
- Software creation and distribution is easier and faster than ever: Startups can now take on giants with little to no funding ahead of time Getting your software into the hands of millions is a download away Your ability to move fast is paramount to your ability to fight off disruption
- 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.
- In 2017 Puppet ran a study to understand the differences in performance of DevOps vs. non DevOps organizations. Quality – Delivery – Happier Teams
- 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
- So how do you adopt a DevOps model? 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. However, nearly all release processes can be simplified down to five stages – source, build, test, deploy, and monitor. 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 make sure 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. Once in production, we monitor our code for unusual activity or errors. 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.
- At AWS we’ve developed tools for our customers that are based on our internal tools we use for our process. See the descriptions in the appendix to describe each.
- At AWS we’ve developed tools for our customers that are based on our internal tools we use for our process. See the descriptions in the appendix to describe each.
- Other compliance and security tools: Chef Inspec & Nessus
- https://secure.flickr.com/photos/dullhunk/202872717/