mirrors/90DaysOfDevOps
1
0
Fork 0
mirror of https://github.com/MichaelCade/90DaysOfDevOps.git synced 2025-02-08 01:54:49 +07:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #210 from ricmmartins/ricmmartins-pt-br

Browse Source
This commit is contained in:
Michael Cade 2022-11-04 22:06:56 +00:00 committed by GitHub
commit ee96a1c9c5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 575 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
pt-br/Days/day01.md Normal file
View File

@ -0,0 +1,64 @@
---
title: '#90DaysOfDevOps - Introdução - Dia 1'
published: true
description: 90DaysOfDevOps - Introdução
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048731
date: '2022-13-13T10:12:40Z'
---
## Introdução - Dia 1
Dia 1 dos nossos 90 dias de aventura para aprender um bom entendimento básico de DevOps e ferramentas que ajudam com uma mentalidade de DevOps.
Essa jornada de aprendizado começou para mim há alguns anos, mas meu foco era em plataformas de virtualização e tecnologias baseadas em nuvem, eu estava olhando principalmente para infraestrutura como código e gerenciamento de configuração de aplicações com Terraform e Chef.
Avançando para março de 2021, tive uma oportunidade incrível de concentrar meus esforços na estratégia _Cloud Native_ na Kasten da Veeam. O que seria um foco maciço no Kubernetes e DevOps além de todo ecossistema em torno dessas tecnologias. Comecei minha jornada de aprendizado e rapidamente percebi que havia um mundo muito amplo além de apenas aprender os fundamentos do Kubernetes e da Containerização, e foi então que comecei a falar com a comunidade e aprender cada vez mais sobre a cultura, ferramentas e processos de DevOps. Então eu comecei a documentar publicamente algumas das áreas que eu queria aprender.
[Então você quer aprender DevOps?](https://blog.kasten.io/devops-learning-curve)
## Deixe a jornada começar
Se você ler o blog acima, verá que este é um conteúdo de alto nível para minha jornada de aprendizado e direi que neste momento não sou nem de longe um especialista em nenhuma dessas seções, mas o que eu queria fazer era compartilhar alguns recursos tanto GRÁTIS quanto pagos, mas uma opção para ambos, pois todos temos circunstâncias diferentes.
Nos próximos 90 dias, quero documentar esses recursos e cobrir essas áreas fundamentais. Eu adoraria que a comunidade também se envolvesse. Compartilhe sua jornada e recursos para que possamos aprender em público e ajudar uns aos outros.
Você verá no _README_ de abertura no repositório do projeto, que dividi as coisas em seções e são 12 semanas mais 6 dias. Nos primeiros 6 dias, exploraremos os fundamentos do DevOps em geral antes de mergulhar em algumas das áreas específicas. De forma alguma esta lista é exaustiva e, novamente, eu adoraria que a comunidade ajudasse a tornar este um recurso útil.
Outro recurso que compartilharei neste momento e que acho que todos deveriam dar uma boa olhada, talvez criar seu próprio mapa mental com assuntos de seu interesse é o seguinte:
[Roteiro do DevOps](https://roadmap.sh/devops)
Achei isso um ótimo recurso quando estava criando minha lista inicial e as postagens no blog sobre esse tópico. Você também pode ver outras áreas em detalhes além dos 12 tópicos que listei aqui neste repositório.
## Primeiros Passos - O que é DevOps?
Há tantos artigos de blog e vídeos do YouTube para listar aqui, mas quando começamos o desafio de 90 dias e nos concentramos em passar cerca de uma hora por dia aprendendo algo novo ou sobre DevOps, achei que seria bom obter alguns de altos níve sobre "o que é DevOps" para começar.
Em primeiro lugar, DevOps não é uma ferramenta. Você não pode comprá-lo, não é um SKU de software ou um repositório GitHub de código aberto que você pode baixar. Também não é uma linguagem de programação, também não é uma arte de magia negra.
DevOps é uma maneira de fazer coisas mais inteligentes no desenvolvimento de software. - Espera... Mas se você não é um desenvolvedor de software deveria se afastar agora e não mergulhar nesse projeto??? Não. De jeito nenhum. Fique... Porque o DevOps reúne uma combinação de desenvolvimento de software e operações. Mencionei anteriormente que eu estava mais no lado da VM e isso geralmente se enquadraria no lado de operações da casa, mas dentro da comunidade, existem pessoas com diferentes origens onde o DevOps é 100% benéfico para o indivíduo, para desenvolvedores e para operações. Engenheiros de QA podem aprender igualmente essas práticas recomendadas tendo uma melhor compreensão do DevOps.
DevOps é um conjunto de práticas que ajudam a atingir o objetivo desse movimento: reduzir o tempo entre a fase de ideação de um produto e seu lançamento em produção para o usuário final ou qualquer que seja uma equipe interna ou ainda, o cliente.
Outra área em que vamos mergulhar nesta primeira semana é em torno da **Metodologia Ágil**. DevOps e Agile são amplamente adotados juntos para obter entrega contínua de suas **Aplicações**.
A conclusão de alto nível é que uma mentalidade ou cultura DevOps serve para reduzir o longo e prolongado processo de lançamento de software de potencialmente anos, para poder lançar versões menores com mais frequência. O outro ponto fundamental a ser entendido aqui é a responsabilidade de um engenheiro de DevOps em dividir os silos entre as equipes que mencionei anteriormente: Desenvolvedores, Operações e QA.
Do ponto de vista do DevOps, **Desenvolvimento, Teste e Implantação** chegam à equipe de DevOps.
O ponto final que farei é que para tornar isso o mais eficaz e eficiente possível, devemos aproveitar a **Automação**.
## Recursos
Estou sempre aberto a adicionar recursos adicionais a esses arquivos README, pois estão aqui como uma ferramenta de aprendizado.
Meu conselho é assistir a todos os itens abaixo e espero que você também tenha captado algo do texto e das explicações acima.
- [DevOps em 5 minutos](https://www.youtube.com/watch?v=Xrgk023l4lI)
- [O que é DevOps? Maneira Fácil](https://www.youtube.com/watch?v=_Gpe1Zn-1fE&t=43s)
- [Roteiro de DevOps 2022 | Roteiro de sucesso 2022](https://www.youtube.com/watch?v=7l_n97Mt0ko)
Se você chegou até aqui, saberá se é aqui que você quer estar ou não. Vejo você no [Dia 2](day02.md).

71
pt-br/Days/day02.md Normal file
View File

@ -0,0 +1,71 @@
---
title: '#90DaysOfDevOps - Responsabilidades de um engenheiro de DevOps - Dia 2'
published: false
description: 90DaysOfDevOps - Responsabilidades de um engenheiro de DevOps
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048699
date: '2022-10-13T11:17:00Z'
---
## Responsabilidades de um engenheiro de DevOps
Espero que você esteja chegando aqui depois de analisar os recursos postados no [Dia1 de #90DiasDeDevOps](dia01.md)
Isso foi brevemente abordado no primeiro post, mas agora devemos nos aprofundar nesse conceito e entender que existem duas partes principais ao criar uma aplicação. Temos a parte de **Desenvolvimento** onde os desenvolvedores de software programam a aplicação e o testam. Em seguida, temos a parte de **Operações** em que a aplicação é implantada e mantida em um servidor.
## DevOps é o elo entre os dois
Para entender DevOps ou as tarefas que um engenheiro de DevOps estaria realizando, precisamos entender as ferramentas ou o processo e a visão geral delas e como elas se unem.
Tudo começa com a aplicação! Você verá que é tudo sobre a aplicação quando se trata de DevOps.
Os desenvolvedores criarão uma aplicação, isso pode ser feito com muitas pilhas de tecnologia diferentes e vamos deixar isso para a imaginação por enquanto, pois entraremos nisso mais tarde. Isso também pode envolver muitas linguagens de programação diferentes, ferramentas de construção, repositórios de código etc.
Como engenheiro de DevOps, você não estará programando a aplicação, mas ter uma boa compreensão dos conceitos de como um desenvolvedor trabalha e dos sistemas, ferramentas e processos que estão usando é a chave para o sucesso.
Em um nível muito alto, você precisará saber como o aplicativo está configurado para se comunicar com todos os seus serviços ou serviços de dados necessários e, em seguida, incluir um requisito de como isso pode ou deve ser testado.
A aplicação precisará ser implantada em algum lugar, vamos simplificar aqui e dizer que será um servidor, não importa onde, mas um servidor. Espera-se que isso seja acessado pelo cliente ou usuário final, dependendo da aplicação que foi criada.
Este servidor precisa ser executado em algum lugar, on-premises, em uma nuvem pública, sem servidor (Ok, eu fui longe demais, não cobriremos sem servidor, mas é uma opção e mais e mais empresas estão indo nessa direção). Alguém precisa criar e configurar esses servidores e prepará-los para a execução do aplicativo. Agora, esse elemento pode chegar a você como engenheiro DevOps para implantar e configurar esses servidores.
Esses servidores executam um sistema operacional e, em geral, isso será Linux, mas temos uma seção ou semana inteira onde abordamos alguns dos conhecimentos fundamentais que você deve obter aqui.
Também é provável que precisemos nos comunicar com outros serviços em nossa rede ou ambiente, portanto, também precisamos ter esse nível de conhecimento sobre rede e configuração, isso pode, em algum grau, também cair aos pés do engenheiro DevOps. Novamente, abordaremos isso com mais detalhes em uma seção dedicada, falando sobre todas as coisas DNS, DHCP, balanceamento de carga etc.
## Jack of all trades, Master of none
_Essa é uma figura de linguagem americana, para se referir a uma pessoa que tem habilidades em diversas atividades, ao invés de estar focada em apenas uma. A melhor tradução ao pé da letra para Português seria "A pessoa que faz tudo e não é especialista em nada"_
Eu vou ser duro nesse ponto, você não precisa ser um especialista em rede ou infraestrutura, você precisa de um conhecimento básico de como colocar as coisas em funcionamento e conversando entre si, da mesma forma que talvez ter um conhecimento básico de uma linguagem de programação sem precisar ser um desenvolvedor. No entanto, você pode estar entrando nisso como um especialista em uma área e isso é uma ótima base para se adaptar a outras áreas.
Você também provavelmente não assumirá o gerenciamento desses servidores ou da aplicação diariamente.
Temos falado sobre servidores, mas a probabilidade é que sua aplicação seja desenvolvida para ser executada como contêineres, que ainda rodam em um servidor na maioria das vezes, mas você também precisará entender não apenas de virtualização, infraestrutura de nuvem como serviço (IaaS ), mas também a conteinerização. O foco nestes 90 dias será mais voltado para os contêineres.
## Visão geral de alto nível
De um lado temos nossos desenvolvedores criando novos recursos e funcionalidades (assim como correções de bugs) para a aplicação.
Do outro lado, temos algum tipo de ambiente, infraestrutura ou servidores que são configurados e gerenciados para executar esta aplicação e se comunicar com todos os seus serviços necessários.
A grande questão é como obtemos esses recursos e correções de bugs em nossos produtos e os disponibilizamos para esses usuários finais?
Como lançamos a nova versão da aplicação? Esta é uma das principais tarefas de um engenheiro DevOps, e o importante aqui não é apenas descobrir como fazer isso uma vez, mas precisamos fazer isso continuamente e de maneira automatizada e eficiente, que também precisa incluir testes!
É aqui que vamos terminar este dia de aprendizado, espero que tenha sido útil. Nos próximos dias, vamos nos aprofundar um pouco mais em mais algumas áreas do DevOps e, em seguida, nas seções que se aprofundam nas ferramentas, nos processos e nos benefícios deles.
## Recursos
Estou sempre aberto a adicionar recursos adicionais a esses arquivos README, pois estão aqui como uma ferramenta de aprendizado.
Meu conselho é assistir a todos os itens abaixo e espero que você também tenha captado algo do texto e das explicações acima.
- [O que é DevOps? - TechWorld with Nana](https://www.youtube.com/watch?v=0yWAtQ6wYNM)
- [O que é DevOps? - GitHub YouTube](https://www.youtube.com/watch?v=kBV8gPVZNEE)
- [O que é DevOps? - IBM YouTube](https://www.youtube.com/watch?v=UbtB4sMaaNM)
- [O que é DevOps? - AWS](https://aws.amazon.com/devops/what-is-devops/)
- [O que é DevOps? - Microsoft](https://docs.microsoft.com/en-us/devops/what-is-devops)
Se você chegou até aqui, saberá se é aqui que você quer estar ou não. Vejo você no [Dia 3](dia03.md).

87
pt-br/Days/day03.md Normal file
View File

@ -0,0 +1,87 @@
---
title: '#90DaysOfDevOps - Foco na Aplicação - Dia 3'
published: false
description: 90DaysOfDevOps - Foco na Aplicação - Dia 3
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048825
---
## Ciclo de vida do DevOps - Foco na Aplicação
À medida que continuarmos nas próximas semanas, em 100% das vezes encontraremos esses títulos (Desenvolvimento Contínuo, Teste, Implantação, Monitoramento) repetidamente. Se você está indo para a função de engenheiro DevOps, a repetibilidade será algo com a qual você se acostumará, mas melhorar constantemente a cada vez é outra coisa que mantém as coisas interessantes.
Neste momento, vamos dar uma olhada na visão de alto nível da aplicação do início ao fim e depois voltar novamente como um loop constante.
### Desenvolvimento
Vamos dar um novo exemplo de uma aplicação. Para começar não temos nada criado e talvez como desenvolvedor, você tenha que discutir com seu cliente ou usuário final os requisitos e criar algum tipo de plano ou requisitos para sua aplicação. Em seguida, precisamos criar a partir dos requisitos nossa nova aplicação.
Com relação às ferramentas nesta etapa, não há nenhum requisito real aqui além de escolher sua IDE e a linguagem de programação que você deseja usar para escrever sua aplicação.
Como engenheiro DevOps, lembre-se de que provavelmente não é você quem está criando este plano ou codificando a aplicação para o usuário final, este será um desenvolvedor habilidoso.
Mas também não faria mal para você poder ler parte do código para poder tomar as melhores decisões de infraestrutura no futuro para sua aplicação.
Mencionamos anteriormente que esta aplicação pode ser escrito em qualquer linguagem. É importante que isso seja mantido usando um sistema de controle de versão, isso é algo que também abordaremos em detalhes mais adiante e, em particular, mergulharemos no **Git**.
Também é provável que não seja um desenvolvedor trabalhando neste projeto, embora esse possa ser o caso, mesmo que as práticas recomendadas exigissem um repositório de código para armazenar e colaborar no código, isso pode ser privado ou público e pode ser implantando de forma hospedada ou privada. De maneira geral, você teria o **GitHub ou GitLab** sendo usado como um repositório de código. Mais uma vez, abordaremos isso como parte de nossa seção sobre **Git** mais adiante.
### Teste
Nesta etapa, temos os nossos requisitos e temos a nossa aplicação a ser desenvolvida. Mas precisamos ter certeza de que estamos testando nosso código em todos os diferentes ambientes que temos disponíveis para nós ou talvez especificamente para a linguagem de programação escolhida.
Essa etapa permite que o time de QA execute teste de bugs. De forma cada vez mais frequente vemos contêineres sendo usados para simular o ambiente de teste que, em geral, pode melhorar as despesas gerais de infraestrutura física ou em nuvem.
Essa etapa provavelmente também será automatizada como parte da próxima área, que é a Integração Contínua.
A capacidade de automatizar esse teste contra 10,100 ou mesmo 1000 engenheiros de controle de qualidade que precisam fazer isso manualmente fala por si, esses engenheiros podem se concentrar em outra coisa dentro da pilha para garantir que você esteja se movendo mais rápido e desenvolvendo mais funcionalidades em vez de testar bugs e software que tende a ser o atraso na maioria dos lançamentos de software tradicionais que usam uma metodologia em cascata.
### Integração
Muito importante, a integração está no meio do ciclo de vida do DevOps. É a prática na qual os desenvolvedores precisam confirmar alterações no código-fonte com mais frequência. Isso pode ser diário ou semanal.
A cada commit, sua aplicação pode passar pelas fases de teste automatizadas e isso permite a detecção antecipada de problemas ou bugs antes da próxima fase.
Agora você pode estar dizendo: "Mas nós não criamos aplicações, nós os compramos de um fornecedor de software". Não se preocupe, muitas empresas fazem isso e continuarão a fazer isso e será o fornecedor de software que está se concentrando nas três fases acima, mas talvez você ainda queira adotar a fase final, pois isso permitirá implantações mais rápidas e eficientes de suas implantações prontas para uso.
Eu também sugeriria que apenas ter esse conhecimento acima é muito importante, pois você pode comprar software de prateleira hoje, mas e amanhã ou no futuro... talvez no próximo trabalho?
### Implantação
Ok, então temos nossa aplicação construída e testada de acordo com os requisitos de nosso usuário final e agora precisamos seguir em frente e implantar essa aplicação em produção para nossos usuários finais consumirem.
Este é o estágio em que o código é implantado nos servidores de produção, agora é onde as coisas ficam extremamente interessantes e é onde o restante de nossos 86 dias se aprofunda nessas áreas. Porque aplicações diferentes exigem hardware ou configurações diferentes. É aqui que o **Gerenciamento de configuração de aplicações** e a **Infraestrutura como Código** podem desempenhar um papel fundamental no ciclo de vida do DevOps. Pode ser que sua aplicação seja **Containerizada**, mas também esteja disponível para execução em uma máquina virtual. Isso também nos leva a plataformas como o **Kubernetes**, que orquestrariam esses contêineres e garantiriam que você tivesse o estado desejado disponível para seus usuários finais.
Desses tópicos ousados, entraremos em mais detalhes nas próximas semanas para obter um melhor conhecimento básico sobre o que são e quando usá-los.
### Monitoramento
As coisas estão se movendo rapidamente aqui e temos nossa aplicação que estamos atualizando continuamente com novos recursos e funcionalidades. E ainda temos nossos testes para garantir que nenhum gremlin seja encontrado. Temos a aplicação em execução em nosso ambiente que pode manter continuamente a configuração e o desempenho necessários.
Mas agora precisamos ter certeza de que nossos usuários finais estão obtendo a experiência de que precisam. Aqui precisamos ter certeza de que o desempenho das nossas aplicações está sendo monitorado continuamente, esta etapa permitirá que seus desenvolvedores tomem melhores decisões sobre melhorias na aplicação em versões futuras para melhor atender os usuários finais.
Esta seção também é onde vamos capturar o ciclo de feedback sobre os recursos que foram implementados e como os usuários finais gostariam de torná-los melhores para eles.
A confiabilidade também é um fator chave aqui, no final das contas, queremos que nossa aplicação esteja disponível o tempo que for necessário. Isso leva a outras áreas de **observabilidade, segurança e gerenciamento de dados** que devem ser monitoradas continuamente e o feedback sempre pode ser usado para melhorar, atualizar e liberar a aplicação continuamente.
Algumas contribuições da comunidade aqui especificamente [@\_ediri](https://twitter.com/_ediri) mencionam que também fazem parte desse processo contínuo termos as equipes de FinOps envolvidas. As aplicações e dados estão sendo executados e armazenados em algum lugar que você deve monitorar continuamente para garantir que, se as coisas mudarem do ponto de vista dos recursos, seus custos não estejam causando grandes problemas financeiros em suas contas de Cloud.
Eu acho que também é um bom momento para trazer à tona o "Engenheiro DevOps" mencionado acima. Embora existam muitas posições de Engenheiro DevOps que as pessoas ocupam, essa não é a maneira ideal de posicionar o processo de DevOps. O que quero dizer é que, ao falar com outras pessoas da comunidade, o título de Engenheiro DevOps não deve ser o objetivo de ninguém, porque realmente qualquer posição deve adotar os processos de DevOps e a cultura explicada aqui. O DevOps deve ser usado em muitas posições diferentes, como engenheiro/arquiteto de tecnologias cloud native, administrador de virtualização, arquiteto/engenheiro de nuvem e administrador de infraestrutura. Isso é para citar alguns, mas o motivo para usar o Engenheiro DevOps acima foi realmente destacar o escopo do processo usado por qualquer uma das posições acima e muito mais.
## Recursos
Estou sempre aberto a adicionar recursos adicionais a esses arquivos README, pois está aqui como uma ferramenta de aprendizado.
Meu conselho é assistir a todos os itens abaixo e espero que você também tenha captado algo do texto e das explicações acima.
- [Desenvolvimento Contínuo](https://www.youtube.com/watch?v=UnjwVYAN7Ns) Também acrescentarei que isso é focado na indústria, mas a cultura enxuta pode ser seguida de perto com o DevOps.
- [Testes Contínuos - IBM YouTube](https://www.youtube.com/watch?v=RYQbmjLgubM)
- [Integração Contínua - IBM YouTube](https://www.youtube.com/watch?v=1er2cjUq1UI)
- [Monitoramento Contínuo](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
- [O fluxo remoto](https://www.notion.so/The-Remote-Flow-d90982e77a144f4f990c135f115f41c6)
- [Fundação FinOps - O que é FinOps](https://www.finops.org/introduction/what-is-finops/)
- [**Não gratuito** O projeto Fênix: Um romance sobre TI, DevOps e como ajudar sua empresa a vencer](https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/)
Se você chegou até aqui, saberá se é aqui que você quer estar ou não. Vejo você no [dia 4](day04.md).

99
pt-br/Days/day04.md Normal file
View File

@ -0,0 +1,99 @@
---
title: '#90DaysOfDevOps - DevOps & Agile - Dia 4'
published: false
description: 90DaysOfDevOps - DevOps & Agile
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048700
---
## DevOps & Agile
Você sabe a diferença entre DevOps e Agile? Eles foram formados como conceitos independentes. Mas agora os dois termos estão se fundindo.
Neste post, examinaremos as diferenças cruciais entre Agile e DevOps e descobriremos por que os dois estão tão conectados.
Acho que um bom lugar para começar, é entender um pouco mais sobre um ângulo comum que tenho visto no aprendizado dessa área é que sobre DevOps vs Agile, embora distintos possuem objetivos e processos semelhantes. Nesta seção, vou resumir isso.
Vamos começar com as definições.
### Desenvolvimento ágil
Agile é uma abordagem que se concentra em fornecer pequenos resultados mais rapidamente, em vez de liberar uma grande interação do produto; o software é desenvolvido em iterações. A equipe lança uma nova versão a cada semana ou mês com atualizações incrementais. O objetivo final do Agile é oferecer uma experiência ideal para os usuários finais.
### DevOps
Nos últimos dias, abordamos isso com algumas maneiras diferentes de descrever os objetivos finais do DevOps. DevOps geralmente descreve o desenvolvimento de software
e práticas de entrega baseadas na cooperação entre desenvolvedores de software e especialistas em operações. Os principais benefícios do DevOps são fornecer um processo de desenvolvimento simplificado e minimizar a falta de comunicação.
## Qual é a diferença entre Agile e DevOps?
A diferença está principalmente nas preocupações. Agile e DevOps têm preocupações diferentes, mas estão ajudando um ao outro. O Agile quer iteração curta, o que só é possível com a automação que o DevOps traz. A Agile quer que o cliente experimente uma versão específica e dê feedback rapidamente, o que só é possível se o DevOps tornar a criação de um novo ambiente algo simples.
### Participantes diferentes
O Agile se concentra na otimização da comunicação entre usuários finais e desenvolvedores, enquanto o DevOps visa desenvolvedores e operações, membros da equipe. Poderíamos dizer que o ágil é orientado para o lado externo (os clientes), enquanto o DevOps é um conjunto de práticas internas.
### Equipe
Agile geralmente se aplica a desenvolvedores de software e gerentes de projeto. As competências dos engenheiros de DevOps estão na interseção de desenvolvimento, controle de qualidade (garantia de qualidade) e operações, pois estão envolvidos em todas as etapas do ciclo do produto e fazem parte da equipe Agile.
### Estruturas Aplicadas
O Agile tem muitas estruturas de gerenciamento para obter flexibilidade e transparência: Scrum > Kanban > Lean > Extreme > Crystal > Dynamic > Feature-Driven. O DevOps se concentra na abordagem de desenvolvimento em colaboração, mas não oferece metodologias específicas. No entanto, DevOps promove práticas como Infraestrutura como Código, Arquitetura como Código, Monitoramento, Self-Healing, automação de testes de ponta a ponta...
### Feedback
No Agile, a principal fonte de feedback é o usuário final, enquanto no DevOps o feedback vem das partes interessadas e da própria equipe tem maior prioridade.
### Áreas-alvo
O Agile se concentra mais no desenvolvimento de software do que na implantação e manutenção. O DevOps também se concentra no desenvolvimento de software, mas seus valores e ferramentas também abrangem estágios de implantação e pós-lançamento, como monitoramento, alta disponibilidade, segurança e proteção de dados.
### Documentação
O Agile prioriza a flexibilidade e as tarefas em relação a documentação e o monitoramento. O DevOps, por outro lado, considera a documentação do projeto como um dos componentes essenciais do projeto.
### Riscos
Os riscos ágeis derivam da flexibilidade da metodologia. Projetos ágeis são difíceis de prever ou avaliar, pois as prioridades e os requisitos estão mudando continuamente.
Os riscos de DevOps derivam de um mal-entendido do termo e da falta de ferramentas adequadas. Algumas pessoas veem o DevOps como uma coleção de software para implantação e integração contínua que não altera a estrutura subjacente do processo de desenvolvimento.
### As ferramentas usadas
As ferramentas ágeis são focadas na colaboração de comunicação gerencial, métricas e processamento de feedback. As ferramentas ágeis mais populares incluem JIRA, Trello, Slack, Zoom, SurveyMonkey e outras.
DevOps usa ferramentas para comunicação de equipe, desenvolvimento de software, implantação e integração como Jenkins, GitHub Actions, BitBucket, etc. Embora ágil e DevOps tenham focos e escopos ligeiramente diferentes, os valores-chave são quase idênticos, portanto, você pode combinar os dois.
## Junte tudo… boa ideia ou não? Vamos discutir?
A combinação de Agile e DevOps traz os seguintes benefícios:
- Gestão flexível e tecnologia poderosa.
- As práticas ágeis ajudam as equipes de DevOps a comunicar suas prioridades com mais eficiência.
- O custo de automação que você precisa pagar por suas práticas de DevOps é justificado por sua exigência ágil de implantação rápida e frequente.
- Leva ao fortalecimento: a equipe adotando práticas ágeis melhorará a colaboração, aumentará a motivação da equipe e diminuirá as taxas de rotatividade de funcionários.
- Como resultado, você obtém uma melhor qualidade do produto.
O Agile permite voltar aos estágios anteriores de desenvolvimento do produto para corrigir erros e evitar o acúmulo de dívida técnica. Para adotar ágil e DevOps
simultaneamente basta seguir estes 7 passos:
1. Unir as equipes de desenvolvimento e operação.
2. Crie equipes de build e execução, todas as preocupações operacionais e de desenvolvimento são discutidas por toda a equipe de DevOps.
3. Mude sua abordagem aos sprints e atribua classificações de prioridade para oferecer tarefas de DevOps que tenham o mesmo valor das tarefas de desenvolvimento. Incentive as equipes de desenvolvimento e operações a trocarem suas opiniões sobre o fluxo de trabalho de outras equipes e possíveis problemas.
4. Incluir QA em todas as etapas de desenvolvimento.
5. Escolha as ferramentas certas.
6. Automatize tudo o que puder.
7. Meça e controle usando resultados numéricos tangíveis.
O que você acha? Você tem visões diferentes? Eu quero ouvir de desenvolvedores, operações, controle de qualidade ou qualquer pessoa que tenha um melhor entendimento de Agile e DevOps que possa passar comentários e feedback sobre isso
### Recursos
- [DevOps para Desenvolvedores – Um dia na vida de um: DevOps Engineer em 2021](https://www.youtube.com/watch?v=2JymM0YoqGA)
- [3 coisas que eu gostaria de saber como engenheiro DevOps](https://www.youtube.com/watch?v=udRNM7YRdY4)
- [Como se tornar um engenheiro de DevOps - feat. Shawn Powers](https://www.youtube.com/watch?v=kDQMjAQNvY4)
Se você chegou até aqui, saberá se é aqui que você quer estar ou não. Vejo você no [Dia 5](day05.md).

85
pt-br/Days/day05.md Normal file
View File

@ -0,0 +1,85 @@
---
title: '#90DaysOfDevOps - Planejamento > Codificação > Build > Testes > Release > Deploy > Operação > Monitoramento > - Dia 5'
published: false
description: 90DaysOfDevOps - PlanPlanejamento > Codificação > Build > Testes > Release > Deploy > Operação > Monitoramento >
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048830
---
## Planejamento > Codificação > Build > Testes > Release > Deploy > Operação > Monitoramento
Hoje vamos nos concentrar nas etapas individuais do início ao fim e no ciclo contínuo de uma aplicação no mundo DevOps.
![DevOps](Images/Day5_DevOps8.png)
### Planejamento
Tudo começa com o processo de planejamento, é onde a equipe de desenvolvimento se reúne e descobre quais tipos de recursos e correções de bugs serão lançados em seu próximo sprint. Esta é uma oportunidade para você como engenheiro DevOps se envolver e aprender com que tipo de coisa virá ao seu caminho e também para influenciar nas decisões deles. Ajudá-los a trabalhar na infraestrutura que você construiu ou orientá-los para algo que funcionará melhor para eles caso não estejam nesse caminho e, portanto, uma coisa importante a destacar aqui é que os desenvolvedores ou a equipe de engenharia de software são seu cliente como engenheiro DevOps, então esta é sua oportunidade de trabalhar com seu cliente antes que ele siga um caminho ruim.
### Codificação
Agora que a sessão de planejamento terminou, eles vão começar a escrever o código. Você pode não estar muito envolvido com isso, mas aqui é um dos lugares em que você pode se envolver com isso. Sempre que eles estiverem escrevendo código, você pode ajudá-los a entender melhor a infraestrutura, então, se eles souberem quais serviços estão disponíveis e como conversar melhor com esses serviços, eles farão isso e, quando terminarem, mesclarão esse código no repositório.
### Build
É aqui que iniciaremos o primeiro de nossos processos de automação, porque pegaremos o código deles e o construiremos juntos. Dependendo de qual linguagem eles estão usando, pode estar compilando ou pode estar criando uma imagem docker a partir desse código. De qualquer forma, vamos passar por esse processo usando nosso pipeline ci/cd.
## Testes
Depois da fase de construção (build), vamos executar alguns testes nele. Agora a equipe de desenvolvimento geralmente escreve o teste, você pode ter algumas informações sobre quais testes são escritos, mas precisamos executar esses testes. O teste é uma maneira de tentar minimizar a introdução de problemas em produção, obviamente não temos como garantir isso, mas queremos chegar o mais próximo possível de garantir que não serão inseridos novos bugs e não serão quebradas coisas que estavam funcionando.
## Release
Assim que os testes passarem, faremos o processo de release (lançamento) e, dependendo novamente do tipo de aplicação em que você está trabalhando, isso pode não ser uma etapa. Você sabe que o código pode estar no repositório do GitHub ou no repositório do git, ou onde quer que ele esteja, mas pode ser o processo de pegar seu código compilado ou a imagem do docker que você criou e colocá-la em um registro ou repositório onde está acessível por seus servidores de produção para o processo de deploy (implantação).
## Deploy
Deploy, é o que fazemos em seguida, porque a implantação é como o final do jogo de tudo isso, porque as implantações (deploys) são quando colocamos o código em produção. Enquanto não fazemos isso é que nossa empresa percebe o valor de todo o esforço e trabalho duro que você e a equipe de engenharia de software colocaram neste produto até este ponto.
## Operação
Uma vez implantado, vamos operá-lo. E operá-lo pode envolver algo como você começar a receber ligações de seus clientes que estão todos irritados porque o site está lento ou a aplicação está lenta, então você precisa descobrir por quê. Em seguida, possivelmente, construa o dimensionamento automático que você sabe lidar, aumente o número de servidores disponíveis durante os períodos de pico e diminua o número de servidores durante os períodos fora do pico de qualquer maneira. Outra coisa operacional que você faz é incluir como um loop de feedback da produção de volta para sua equipe de operações informando sobre os principais eventos que aconteceram na produção, fazer rollback do deploy. Isso pode ou não ser automatizado, dependendo do seu ambiente, o objetivo é sempre automatizá-lo quando possível. Existem alguns ambientes onde você possivelmente precisa fazer algumas etapas antes de estar pronto para fazer isso, mas idealmente você deseja implantar automaticamente como parte da sua automação. Porém caso você esteja fazendo isso, pode ser uma boa idéia incluir em suas etapas operacionais algum tipo de notificação para que sua equipe de operações saiba que uma implantação aconteceu.
## Monitoramento
All of the above parts lead to the final step because you need to have monitoring, especially around operational issues auto-scaling troubleshooting like you don't know
there's a problem if you don't have monitoring in place to tell you that there's a problem so some of the things you might build monitoring for are memory utilization CPU utilization disk space, API endpoint, response time, how quickly that endpoint is responding and a big part of that as well is logs. Logs give developers the ability to see what is happening without having to access production systems.
## Rinse & Repeat
Once that's in place you go right back to the beginning to the planning stage and go through the whole thing again
## Continuous
Many tools help us achieve the above continuous process, all this code and the ultimate goal of being completely automated, cloud infrastructure or any environment is often described as Continuous Integration/ Continuous Delivery/Continous Deployment or “CI/CD” for short. We will spend a whole week on CI/CD later on in the 90 Days with some examples and walkthroughs to grasp the fundamentals.
### Continuous Delivery
Continuous Delivery = Plan > Code > Build > Test
### Continuous Integration
This is effectively the outcome of the Continuous Delivery phases above plus the outcome of the Release phase. This is the case for both failure and success but this is fed back into continuous delivery or moved to Continuous Deployment.
Continuous Integration = Plan > Code > Build > Test > Release
### Continuous Deployment
If you have a successful release from your continuous integration then move to Continuous Deployment which brings in the following phases
CI Release is Success = Continuous Deployment = Deploy > Operate > Monitor
You can see these three Continuous notions above as the simple collection of phases of the DevOps Lifecycle.
This last bit was a bit of a recap for me on Day 3 but think this makes things clearer for me.
### Resources
- [DevOps for Developers – Software or DevOps Engineer?](https://www.youtube.com/watch?v=a0-uE3rOyeU)
- [Techworld with Nana -DevOps Roadmap 2022 - How to become a DevOps Engineer? What is DevOps?](https://www.youtube.com/watch?v=9pZ2xmsSDdo&t=125s)
- [How to become a DevOps Engineer in 2021 - DevOps Roadmap](https://www.youtube.com/watch?v=5pxbp6FyTfk)
If you made it this far then you will know if this is where you want to be or not.
See you on [Day 6](day06.md).

169
pt-br/README.md Normal file
View File

@ -0,0 +1,169 @@
# 90DaysOfDevOps
<p align="center">
<img src="../logo.png?raw=true" alt="90DaysOfDevOps Logo" width="50%" height="50%" />
</p>
Versão em Portugês | [中文版本](zh_cn/README.md) | [繁體中文版本](zh_tw/README.md)| [日本語版](ja/README.md) | [Wersja Polska](pl/README.md) | [Tiếng Việt](vi/README.md)
Este repositório é usado para documentar minha jornada para obter um melhor conhecimento básico de "DevOps". Estarei começando esta jornada no dia 1º de janeiro de 2022, mas a ideia é que levemos 90 dias, o que acontece de 1º de janeiro a 31 de março.
A razão para documentar esses dias é para que outros possam tirar algum proveito disso e também melhorar os recursos.
O objetivo é levar 90 dias, 1 hora por dia, para abordar mais de 13 áreas de "DevOps" para um conhecimento básico.
Isso **não abrangerá todas as coisas** sobre "DevOps", mas abrangerá as áreas que considero que beneficiarão meu aprendizado e compreensão em geral.
[![ko-fi](https://ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/N4N33YRCS)
A maneira mais rápida de entrar em contato será via Twitter, meu contato é [@MichaelCade1](https://twitter.com/MichaelCade1)
## Progresso
- [✔️] ♾️ 1 > [Introdução](Days/day01.md)
### O que é e por que usamos DevOps
- [✔️] ♾️ 2 > [Responsabilidades de um engenheiro de DevOps](Days/day02.md)
- [✔️] ♾️ 3 > [Ciclo de vida do DevOps - Foco no aplicativo](Days/day03.md)
- [✔️] ♾️ 4 > [DevOps & Agile](Days/day04.md)
- [✔️] ♾️ 5 > [Planejamento > Codificação > Build > Teste > Release > Deployment > Operação > Monitoramento >](Days/day05.md)
- [✔️] ♾️ 6 > [DevOps - As histórias reais](Days/day06.md)
### Aprendendo uma linguagem de programação
- [✔️] ⌨️ 7 > [O panorama geral: DevOps & Aprendizado de uma linguagem de programação](Days/day07.md)
- [✔️] ⌨️ 8 > [Configurando seu ambiente DevOps para Go & "Hello World"](Days/day08.md)
- [✔️] ⌨️ 9 > [Vamos explicar o código "Hello World"](Days/day09.md)
- [✔️] ⌨️ 10 > [O workspace Go & compilação & execução de código](Days/day10.md)
- [✔️] ⌨️ 11 > [Variáveis, Constantes & Tipos de Dados](Days/day11.md)
- [✔️] ⌨️ 12 > [Obtendo a entrada do usuário com ponteiros e um programa finalizado](Days/day12.md)
- [✔️] ⌨️ 13 > [Tweet sey progresso com nosso novo aplicativo](Days/day13.md)
### Conhecendo o básico do Linux
- [✔️] 🐧 14 > [O panorama geral: DevOps e Linux](Days/day14.md)
- [✔️] 🐧 15 > [Comandos Linux para DevOps (Na verdade para todo mundo)](Days/day15.md)
- [✔️] 🐧 16 > [Gerenciando seu sistema Linux, sistema de arquivos & storage](Days/day16.md)
- [✔️] 🐧 17 > [Editores de texto - nano vs vim](Days/day17.md)
- [✔️] 🐧 18 > [SSH & Servidor Web (LAMP)](Days/day18.md)
- [✔️] 🐧 19 > [Automatize tarefas com scripts bash](Days/day19.md)
- [✔️] 🐧 20 > [Configuração da estação de trabalho do dsenvolvedor - Com tudo perfeito](Days/day20.md)
### Compreendendo redes
- [✔️] 🌐 21 > [O panorama geral: DevOps e Redes](Days/day21.md)
- [✔️] 🌐 22 > [O Modelo OSI - As 7 Camadas](Days/day22.md)
- [✔️] 🌐 23 > [Protocolos de rede](Days/day23.md)
- [✔️] 🌐 24 > [Automação de Rede](Days/day24.md)
- [✔️] 🌐 25 > [Python para automação de rede](Days/day25.md)
- [✔️] 🌐 26 > [Construindo nosso laboratório](Days/day26.md)
- [✔️] 🌐 27 > [Praticando Python & Redes](Days/day27.md)
### Atenha-se a um provedor de nuvem
- [✔️] ☁️ 28 > [O panorama geral: DevOps e a nuvem](Dias/dia28.md)
- [✔️] ☁️ 29 > [Fundamentos do Microsoft Azure](Dias/dia29.md)
- [✔️] ☁️ 30 > [Modelos de Segurança do Microsoft Azure](Dias/dia30.md)
- [✔️] ☁️ 31 > [Modelos de Computação do Microsoft Azure](Dias/dia31.md)
- [✔️] ☁️ 32 > [Modelos de armazenamento e banco de dados do Microsoft Azure](Days/day32.md)
- [✔️] ☁️ 33 > [Modelos de Rede do Microsoft Azure + Gerenciamento do Azure](Days/day33.md)
- [✔️] ☁️ 34 > [Cenários práticos do Microsoft Azure](Dias/dia34.md)
### Use o Git de forma eficaz
- [✔️] 📚 35 > [O panorama geral: Git - Controle de Versão](Days/day35.md)
- [✔️] 📚 36 > [Instalando e configurando o Git](Days/day36.md)
- [✔️] 📚 37 > [Conhecendo o Git](Dias/dia37.md)
- [✔️] 📚 38 > ["Staging" e "Changing"](Dias/dia38.md)
- [✔️] 📚 39 > [Visualização, "unstaging", descarte e restauração](Dias/dia39.md)
- [✔️] 📚 40 > [Rede Social para código](Dias/dia40.md)
- [✔️] 📚 41 > [O fluxo de trabalho do código aberto](Days/day41.md)
### Recipientes
- [✔️] 🏗️ 42 > [O panorama geral: Contêineres](Dias/dia42.md)
- [✔️] 🏗️ 43 > [O que é o Docker e preparação da instalação](Days/day43.md)
- [✔️] 🏗️ 44 > [Imagens Docker & Prática com Docker Desktop](Days/day44.md)
- [✔️] 🏗️ 45 > [A anatomia de uma imagem do Docker](Days/day45.md)
- [✔️] 🏗️ 46 > [Docker Compose](Days/day46.md)
- [✔️] 🏗️ 47 > [Rede & Segurança com Docker](Days/day47.md)
- [✔️] 🏗️ 48 > [Alternativas ao Docker](Dias/dia48.md)
### Kubernetes
- [✔️] ☸ 49 > [O panorama geral: Kubernetes](Dias/dia49.md)
- [✔️] ☸ 50 > [Escolhendo sua plataforma Kubernetes](Dias/dia50.md)
- [✔️] ☸ 51 > [Implantando seu primeiro cluster Kubernetes](Days/day51.md)
- [✔️] ☸ 52 > [Configurando um cluster Kubernetes com múltiplos nós](Days/day52.md)
- [✔️] ☸ 53 > [Visão geral do Rancher - Prática](Dias/dia53.md)
- [✔️] ☸ 54 > [Implantação de aplicações com Kubernetes](Dias/dia54.md)
- [✔️] ☸ 55 > ["State" e "Ingress" no Kubernetes](Dias/dia55.md)
### Aprenda a infraestrutura como código
- [✔️] 🤖 56 > [O panorama geral: IaC](Dias/dia56.md)
- [✔️] 🤖 57 > [Uma introdução ao Terraform](Days/day57.md)
- [✔️] 🤖 58 > [Linguagem de Configuração do HashiCorp (HCL)](Days/day58.md)
- [✔️] 🤖 59 > [Crie uma VM com Terraform & Variáveis](Days/day59.md)
- [✔️] 🤖 60 > [Contêineres Docker, Provisionadores & Módulos](Days/day60.md)
- [✔️] 🤖 61 > [Kubernetes e múltiplos ambientes](Dias/dia61.md)
- [✔️] 🤖 62 > [Testes, ferramentas e alternativas](Dias/dia62.md)
### Automatize o gerenciamento de configuração
- [✔️] 📜 63 > [O panorama gera: Gerência de Configuração](Days/day63.md)
- [✔️] 📜 64 > [Ansible: Primeiros passos](Days/day64.md)
- [✔️] 📜 65 > [Manual do Ansible](Dias/dia65.md)
- [✔️] 📜 66 > [Manual do Ansible - Continuação...](Dias/dia66.md)
- [✔️] 📜 67 > [Usando funções e implantando um balanceador de carga](Days/day67.md)
- [✔️] 📜 68 > ["Tags", Variáveis, Inventário & Servidor de Configuração de Banco de Dados](Days/day68.md)
- [✔️] 📜 69 > [Todas as outras coisas sobre Ansible - "Automation Controller", "AWX", "Vault"](Days/day69.md)
### Crie pipelines de CI/CD
- [✔️] 🔄 70 > [O panorama gera: Pipelines de CI/CD](Dias/dia70.md)
- [✔️] 🔄 71 > [O que é Jenkins?](Dias/dia71.md)
- [✔️] 🔄 72 > [Colocando as mãos no Jenkins](Days/day72.md)
- [✔️] 🔄 73 > [Construindo um pipeline do Jenkins](Days/day73.md)
- [✔️] 🔄 74 > ["Hello World" - Jenkinsfile App Pipeline](Days/day74.md)
- [✔️] 🔄 75 > [Visão geral das ações do GitHub](Days/day75.md)
- [✔️] 🔄 76 > [Visão geral do ArgoCD](Dias/dia76.md)
### Monitoramento, gerenciamento de log e visualização de dados
- [✔️] 📈 77 > [O panorama geral: Monitoramento](Days/day77.md)
- [✔️] 📈 78 > [Prática com ferramentas de monitoramento](Dias/dia78.md)
- [✔️] 📈 79 > [O panorama geral: gerenciamento de logs](Dias/dia79.md)
- [✔️] 📈 80 > [ELK Stack](Dias/dia80.md)
- [✔️] 📈 81 > [Fluentd & FluentBit](Dias/dia81.md)
- [✔️] 📈 82 > [EFK Stack](Dias/dia82.md)
- [✔️] 📈 83 > [Visualização de Dados - Grafana](Dias/dia83.md)
### Armazene e proteja seus dados
- [✔️] 🗃️ 84 > [O panorama geral: Gerenciamento de dados](Dias/dia84.md)
- [✔️] 🗃️ 85 > [Serviços de Dados](Dias/dia85.md)
- [✔️] 🗃️ 86 > [Fazer backup de todas as plataformas](Dias/dia86.md)
- [✔️] 🗃️ 87 > [Prática de backup e recuperação](Dias/dia87.md)
- [✔️] 🗃️ 88 > [Backups focados em aplicações](Dias/dia88.md)
- [✔️] 🗃️ 89 > [Recuperação de desastres](Dias/dia89.md)
- [✔️] 🗃️ 90 > [Mobilidade de dados e aplicações](Dias/dia90.md)
## Licença
Amparado sob: [![CC BY-NC-SA 4.0][cc-by-nc-sa-shield]][cc-by-nc-sa]
Esta obra está licenciada sob
[Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License][cc-by-nc-sa].
[![CC BY-NC-SA 4.0][cc-by-nc-sa-image]][cc-by-nc-sa]
## Histórico de estrelas
[![Star History Chart](https://api.star-history.com/svg?repos=MichaelCade/90DaysOfDevOps&type=Timeline)](https://star-history.com/#MichaelCade/90DaysOfDevOps&Timeline)
[cc-by-nc-sa]: http://creativecommons.org/licenses/by-nc-sa/4.0/
[cc-by-nc-sa-image]: https://licensebuttons.net/l/by-nc-sa/4.0/88x31.png
[cc-by-nc-sa-shield]: https://img.shields.io/badge/License-CC%20BY--NC--SA%204.0-lightgrey.svg