From 0d0274ddef0d8bf31ce48209e788603e2c53f280 Mon Sep 17 00:00:00 2001 From: Matheus Paes Date: Mon, 25 Mar 2024 18:41:45 -0300 Subject: [PATCH] initial commit pt-br translation --- .gitignore | 1 + Dockerfile | 4 +- content/pt/_index.html | 32 +++++++ content/pt/learn/_index.md | 27 ++++++ content/pt/learn/overview/_index.md | 7 ++ content/pt/learn/overview/ai.md | 37 ++++++++ content/pt/learn/overview/pace.md | 136 +++++++++++++++++++++++++++ content/pt/learn/overview/problem.md | 130 +++++++++++++++++++++++++ content/pt/learn/overview/risks.md | 32 +++++++ docker-compose.yaml | 6 +- hugo.toml | 11 ++- 11 files changed, 416 insertions(+), 7 deletions(-) create mode 100644 content/pt/_index.html create mode 100755 content/pt/learn/_index.md create mode 100644 content/pt/learn/overview/_index.md create mode 100644 content/pt/learn/overview/ai.md create mode 100644 content/pt/learn/overview/pace.md create mode 100644 content/pt/learn/overview/problem.md create mode 100644 content/pt/learn/overview/risks.md diff --git a/.gitignore b/.gitignore index 6379857..3704046 100644 --- a/.gitignore +++ b/.gitignore @@ -1,5 +1,6 @@ node_modules/ /resources/ +public/ # vim temporary files *~ diff --git a/Dockerfile b/Dockerfile index d525d3b..9c911a6 100644 --- a/Dockerfile +++ b/Dockerfile @@ -1,5 +1,5 @@ # This image is to latest than which one is running online -# FROM klakegg/hugo:ext-alpine -FROM klakegg/hugo@sha256:b66d1bca06dea66dc713a960b290e8df193cb922e09051aecb0fe932e799d652 as hugo_0-88-1 +FROM klakegg/hugo:ext-alpine +# FROM klakegg/hugo@sha256:b66d1bca06dea66dc713a960b290e8df193cb922e09051aecb0fe932e799d652 as hugo_0-88-1 RUN apk add git diff --git a/content/pt/_index.html b/content/pt/_index.html new file mode 100644 index 0000000..cf1cdec --- /dev/null +++ b/content/pt/_index.html @@ -0,0 +1,32 @@ ++++ +title = "CD Foundation Melhores Práticas" +linkTitle = "Melhores Práticas" + ++++ + +{{< blocks/cover title="Continuous Delivery Melhores Práticas" height="min" color="orange" >}} +
+ }}"> + Saiba Mais + +
+ +Aprenda como as melhores práticas de entrega contínua podem ajudar você a desenvolver, construir e entregar software de forma mais rápida, confiável e segura. + +{{< /blocks/cover >}} + +{{< blocks/section color="dark" type="row">}} + +{{% blocks/feature icon="fa-tasks" title="Avalie" url="learn/assess" %}} +Avalie o seu momento atual e identifique as mudanças a serem priorizadas. +{{% /blocks/feature %}} + +{{% blocks/feature icon="fa-book-open" title="Aprender" url="/learn" %}} +Aprenda sobre as melhores práticas de entrega contínua. +{{% /blocks/feature %}} + +{{% blocks/feature icon="fa-users" title="Comunidade" url="/community" %}} +Explore as formas como os membros da comunidade implementam as melhores práticas. +{{% /blocks/feature %}} + +{{< /blocks/section >}} diff --git a/content/pt/learn/_index.md b/content/pt/learn/_index.md new file mode 100755 index 0000000..0adbee5 --- /dev/null +++ b/content/pt/learn/_index.md @@ -0,0 +1,27 @@ + +--- +title: "Melhores práticas entrega contínua" +linkTitle: "Aprender" +weight: 20 +menu: + main: + weight: 20 +layout: docs +--- + +Esta seção fornece detalhes sobre as melhores práticas de entrega contínua. + +As práticas nesta seção são neutras em relação aos fornecedores. Para ler estudos de caso ou implementações opinativas com ferramentas específicas, dê uma olhada na seção +[Comunidade](/community). Você também pode encontrar recursos adicionais na seção +[Recursos](/resources). + +## Como usar este guia + +Se você é novo em práticas de entrega contínua e deseja entender seus benefícios e pré-requisitos para começar sua jornada, leia a +[Visão Geral](overview). + +Se você tem alguma familiaridade com a entrega contínua, mas precisa de ajuda para descobrir o que priorizar, leia sobre ferramentas de [assessment](assess) para ajudá-lo a identificar áreas nas quais focar. + +O restante das subseções deste guia fornece informações sobre áreas-chave da entrega contínua. + +Algumas práticas dependem de outras, enquanto outras abrangem todo o ciclo de vida do software. Por exemplo, as melhores práticas para integração contínua dependem do controle de versão. As melhores práticas de segurança são mais eficazes quando aplicadas em toda a cadeia de fornecimento de software. As melhores práticas também envolvem colaboração entre equipes funcionais. \ No newline at end of file diff --git a/content/pt/learn/overview/_index.md b/content/pt/learn/overview/_index.md new file mode 100644 index 0000000..9297eff --- /dev/null +++ b/content/pt/learn/overview/_index.md @@ -0,0 +1,7 @@ +--- +title: Por onde começar? +linkTitle: "Por onde começar?" +weight: 1 +description: > + Uma Introdução à Entrega Contínua +--- diff --git a/content/pt/learn/overview/ai.md b/content/pt/learn/overview/ai.md new file mode 100644 index 0000000..369c6f4 --- /dev/null +++ b/content/pt/learn/overview/ai.md @@ -0,0 +1,37 @@ +--- +title: "IA & Aprendizado de Máquina" +linkTitle: "IA & Aprendizado de Máquina" +weight: 100 +author: Terry Cox +description: >- + MLOps: Modelos também são ativos +--- +Muitos produtos incluem aprendizado de máquina como um componente tecnológico e o processo de gerenciamento de aprendizado de máquina em produção é geralmente referido como MLOps, no entanto, existem visões amplamente divergentes sobre o que isso significa na prática nesse campo em desenvolvimento. + +Um mal-entendido comum é tratar o aprendizado de máquina como uma disciplina independente e isolada com ferramentas otimizadas puramente para a conveniência de equipes de ciência de dados entregando modelos autônomos. Isso é problemático porque nos leva de volta aos padrões de desenvolvimento da era pré-DevOps, onde equipes trabalham isoladamente, com uma visão parcial do espaço do problema, e lançam ativos para outras equipes, a jusante, para implantar e manter. + +Na realidade, o componente de aprendizado de máquina de um produto representa cerca de 5-10% do esforço necessário para levar esse produto ao mercado, escalá-lo e mantê-lo ao longo de sua vida útil. O importante é gerenciar o produto como um todo, não os modelos ou qualquer outra classe específica de tecnologia incluída no produto. MLOps deve, portanto, ser visto como a prática de integrar capacidades de ciência de dados à sua abordagem DevOps e permitir que ativos de aprendizado de máquina sejam gerenciados exatamente da mesma maneira que os outros ativos que compõem seu produto. + +Isso implica em estender a "máquina que constrói seu produto" para permitir que ela construa seus ativos de aprendizado de máquina ao mesmo tempo. Isso acaba tendo vantagens significativas sobre a abordagem manual comum em equipes de ciência de dados. + +Primeiramente, seus ativos de ciência de dados devem ser versionados. Isso inclui componentes relativamente familiares como scripts de treinamento e modelos treinados, mas requer que você também estenda sua capacidade de versionamento para referenciar versões explícitas de conjuntos de dados de treinamento e teste, que de outra forma tendem a ser tratados como buckets efêmeros de dados operacionais que nunca têm o mesmo estado duas vezes. + +Seu processo de treinamento deve ser automatizado, desde scripts de treinamento que são eles próprios ativos gerenciados que incluem testes de aceitação automatizados. Tenha em mente a ideia de que os modelos que você está produzindo não são blocos de código ótimos que podem ser depurados, mas são aproximações de um resultado desejado que podem ser considerados adequados se atenderem a um conjunto de critérios predefinidos para sua função de perda. Modelos úteis são, portanto, descobertos através do treinamento, e não criados através da introspecção, e a qualidade de seus modelos representará uma compensação entre os dados disponíveis para o treinamento, as técnicas aplicadas, a sintonia realizada para hiperparâmetros e os recursos disponíveis para treinamento contínuo para descobrir instâncias de modelos melhores. + +Muitos desses fatores podem ser otimizados por automação como parte do seu sistema de construção. Se seu sistema de construção criar a infraestrutura necessária para executar uma execução de treinamento dinamicamente, sob demanda, e avaliar a qualidade do modelo resultante, você pode expandir seu espaço de busca e ajustar seus hiperparâmetros executando vários treinamentos em paralelo e selecionando entre o conjunto de modelos criados. + +Uma grande parte do gerenciamento bem-sucedido de ativos de aprendizado de máquina reside na capacidade de otimizar sua utilização de recursos caros de hardware de processamento, tanto durante o treinamento quanto na inferência operacional. Gerenciar manualmente clusters de VMs com recursos de GPU ou TPU anexados rapidamente se torna insustentável, o que significa que você pode acumular grandes custos por amarrar recursos caros que na verdade não estão sendo utilizados para trabalho produtivo. Seu sistema de construção precisa ser capaz de alocar recursos para trabalhos de maneira previsível, limitando seus gastos máximos contra orçamentos definidos, alertando sobre o uso excessivo e permitindo que você priorize determinadas tarefas sobre outras onde os recursos são escassos em disponibilidade. + +É importante estar ciente de que além de exemplos triviais que podem ser executados na memória em um único dispositivo de computação, grande parte do aprendizado de máquina está no domínio da computação complexa, de alto desempenho e distribuída. O desafio é decompor um problema de forma que petabytes de dados de treinamento possam ser úteis divididos em partes pequenas o suficiente para serem processados de forma útil por hardware com apenas gigabytes de RAM, distribuídos em operações paralelas que são independentes o suficiente para reduzir significativamente o tempo decorrido de um treinamento. Mover tantos dados através de milhares de nós de processamento de forma que garanta que os dados corretos estejam no nó certo no momento ideal é um problema conceitual para o qual os humanos são pouco adequados para otimizar e o custo dos erros pode ser facilmente multiplicado por ordens de magnitude. + +Deve-se considerar os caminhos de ida e volta neste ciclo de vida do produto. Seu processo de construção deve buscar otimizar o treinamento e a implantação de modelos versionados em ambientes de produção, mas também permitir um rastreamento claro, para que, para qualquer modelo em produção, seja possível seguir sua jornada inversa para que o impacto de incidentes em produção possa ser mitigado a um custo mínimo. + +No ciclo avançado, existem requisitos adicionais para testar ativos de aprendizado de máquina, que devem ser automatizados tanto quanto possível. Os modelos são tipicamente sistemas de tomada de decisão que devem ser submetidos à detecção de viés e validação de justiça, com verificações éticas específicas para garantir que o comportamento do modelo esteja em conformidade com os valores corporativos. + +Em alguns casos, será um requisito legal que o modelo seja comprovável ou explicável, de modo que uma investigação retrospectiva possa entender por que o modelo tomou uma decisão específica. Nesses casos, deve-se esperar que o ciclo de vida evolutivo do modelo inclua a necessidade de ser capaz de retroceder pelo processo de treinamento a partir de um incidente em produção, desencadeando o retrabalho e os testes de regressão para garantir que os erros sejam corrigidos em lançamentos subsequentes. + +Os modelos também requerem avaliação de segurança e privacidade antes do lançamento. Isso deve se dar na forma de testes adversariais, nos quais o modelo é submetido a dados de entrada manipulados com o objetivo de forçar uma decisão previsível ou revelar dados de treinamento pessoalmente identificáveis na saída. Note que sempre há um equilíbrio entre explicabilidade e privacidade em aplicações de aprendizado de máquina, então essa classe de teste é extremamente importante. + +O sistema de construção deve ser capaz de gerenciar adequadamente a sincronização do lançamento de modelos e os serviços convencionais que os consomem, em produção. Sempre há um problema de acoplamento entre instâncias de modelo e os serviços que hospedam e consomem operações de inferência. Deve-se esperar que múltiplas versões de um determinado modelo sejam implantadas em paralelo, em produção, então todos os serviços associados devem ser versionados e gerenciados adequadamente. + +Observe que em algumas regiões geográficas, é possível que os clientes retirem o direito de usar dados que podem compor parte do conjunto de treinamento para modelos de produção. Isso pode desencadear a necessidade de eliminar esses dados do seu conjunto de treinamento, retrabalhar e implantar novamente quaisquer modelos que tenham consumido esses dados anteriormente. Se você não pode fazer isso automaticamente, há o risco de que isso possa ser usado como um vetor de ataque de negação de serviço contra seu negócio, forçando-o a ciclos de retrabalho e reimplementação manualmente caros ou expondo-o a litígios por violações de legislação de privacidade. \ No newline at end of file diff --git a/content/pt/learn/overview/pace.md b/content/pt/learn/overview/pace.md new file mode 100644 index 0000000..64394bc --- /dev/null +++ b/content/pt/learn/overview/pace.md @@ -0,0 +1,136 @@ +--- +title: "Ir mais devagar para ir mais rápido." +linkTitle: "Ir mais devagar para ir mais rápido." +weight: 20 +author: Terry Cox +description: >- + Compreendendo o que faz a maior diferença ao otimizar para o sucesso +--- + +Para uma única pessoa, trabalhando isoladamente em um único problema, o caminho mais rápido é uma linha reta de A a B. + +A abordagem clássica para tentar acelerar uma equipe é fazer melhorias lineares nas atividades de cada membro da equipe, cortando caminhos até que eles estejam fazendo a atividade mínima possível para chegar ao resultado desejado. Levado ao extremo, isso frequentemente resulta na negligência de requisitos não funcionais essenciais, como segurança, privacidade ou resiliência. Isso é, no entanto, um anti-padrão por razões mais sutis e perniciosas - laços internos e escalares exponenciais... + +Ao tentar completar uma tarefa com pressa, tendemos a usar uma abordagem manual e de força bruta para realizar as tarefas. Precisa configurar um ambiente? "Oh, eu vou apenas pesquisar e copiar e colar alguns comandos." Precisa testar algo? "Posso verificar isso exercitando a UI." + +Todas essas tarefas levam tempo para serem realizadas com precisão, mas em nossas mentes, orçamos elas como bloqueadores únicos para o progresso que precisamos superar. Infelizmente, em nossas mentes, também estamos assumindo uma linha reta, um caminho feliz para uma solução funcional. Na prática, estamos sempre iterando em direção a um resultado e acabamos tendo que repetir essas tarefas mais vezes do que orçamos. + +Nessas circunstâncias, percebemos que estamos atrasando e começamos a ficar descuidados ao repetir as tarefas chatas e manuais que não tínhamos orçado mentalmente. Isso tem o efeito de introduzir uma nova classe de erros, que também não tínhamos considerado em nossas expectativas, nos desviando ainda mais do caminho. + +Se essas tarefas manuais caem dentro de um laço interno de nosso processo de construção e lançamento iterativo, elas são capazes de adicionar sobrecarga e risco consideráveis ao processo. Identificar essas tarefas desde o início e orçar para automatá-las no primeiro dia compensa o investimento assim que as coisas saem do território não antecipado. + +Os benefícios disso são fáceis o suficiente para os indivíduos visualizarem. O próximo problema, no entanto, é mais sutil e mais impactante. + +Como discutimos anteriormente, trabalhar com artefatos 'invisíveis' como sistemas de software significa que as equipes têm que gerenciar o problema de comunicar o que é necessário, o que está sendo feito e que dívida técnica permanece. Em uma equipe de 'n' pessoas, o número de caminhos de comunicação possíveis aumenta com n2-n e esse fator de escala exponencial pode rapidamente anular toda a produtividade. + +Da mesma forma, se cada pessoa da equipe adotar uma abordagem única para resolver um determinado problema, a quantidade de esforço necessária para a equipe entender como algo funciona e como modificá-lo também aumentará com n2. + +À medida que seu produto cresce, o número de clientes e o volume de transações também aumentam exponencialmente. + +Como resultado, comportamentos que funcionaram bem em equipes pequenas com problemas pequenos de repente e inesperadamente se tornam completamente ingovernáveis com aumentos bastante pequenos na escala. + +Para operar com sucesso em escala, é fundamental mitigar o impacto da complexidade sempre que possível. Implementar processos consistentes e repetíveis que se apliquem em todos os lugares é um caminho para ter um conjunto restrito de atividades complexas que devem ser aprendidas por todos, mas que se aplicam a todas as atividades futuras. Isso adiciona uma sobrecarga linear incremental a cada atividade, mas reduz o risco de complexidade de escala exponencial. + +A implicação disso é que há a necessidade de adotar um ciclo de lançamento unificado para todos os ativos. Ajuda a pensar no seu processo de lançamento como uma máquina que assa versões do seu produto. Todo ativo que compõe seu produto é ou um material bruto que é uma entrada para a máquina, ou é algo que é cozido pela máquina como um produto intermediário. O processo de assar tem uma série de etapas que são aplicadas aos ingredientes para criar um produto final perfeito, juntamente com estágios de controle de qualidade que rejeitam lotes estragados. + +Se você tiver ingredientes que não se encaixam na máquina, ou etapas de processo necessárias que a máquina não conhece, não poderá esperar criar um produto final consistente e de alta qualidade. + +Vale ressaltar este ponto. Se sua intenção é construir um produto que seja um sistema de software que produza algum valor para os clientes, você deve ter a expectativa de que também precisará possuir um segundo sistema, que é a máquina que monta seu produto. Esses sistemas estão relacionados, mas são ortogonais. Ambos têm um custo de propriedade e exigirão manutenção contínua, suporte e melhoria. A lucratividade do seu produto está relacionada à eficácia da máquina que o monta, assim como sua capacidade de evoluir futuros produtos para identificar o ajuste do mercado de produtos. + +Então, quais são os principais recursos de uma máquina que fabrica seu produto? + +Vamos começar olhando para os ingredientes que você está colocando na máquina. Estes geralmente serão compostos pelo código fonte que suas equipes de desenvolvimento criaram, dependências de terceiros que elas selecionaram e conjuntos de dados que o negócio agregou. Estas são operações centradas em pessoas que carregam consigo um risco aumentado de erro humano e um conjunto de suposições associadas que podem ou não se alinhar aos resultados necessários para o seu produto final. + +Qualquer componente neste nível terá sido criado por um indivíduo ou pequena equipe e deve-se assumir que este trabalho foi realizado com um entendimento mínimo de como o componente interagirá com o restante do seu produto. + +Isso apresenta algumas questões-chave que seu sistema de construção deve ser capaz de validar: + +* O componente pode ser compilado em seu ambiente oficial? + +* Ele se comporta como o desenvolvedor esperava? + +* Ele se comporta como outros desenvolvedores, que são clientes de seu serviço, esperavam? + +* Ele está alinhado aos requisitos funcionais e não funcionais do produto? + +Vamos abordar brevemente a importância de ambientes consistentes. A justificativa mais comum ouvida dentro das equipes de desenvolvimento provavelmente é "Bom, funciona na minha máquina!" + +O ambiente no qual você constrói e testa seu código representa outro conjunto de dependências que devem ser gerenciadas para manter a consistência em todo o produto final. É difícil fazer isso de forma eficaz se seus ambientes são computadores físicos, já que o laptop de cada desenvolvedor pode estar configurado de forma diferente e isso pode variar significativamente do hardware usado no ambiente de construção, no ambiente de preparação e na produção. + +A virtualização e a contêinerização tornam muito mais fácil ter uma definição padrão para um ambiente de construção e um ambiente de execução que possa ser usado consistentemente ao longo do ciclo de vida do componente sendo mantido. Discutiremos isso com mais detalhes posteriormente, mas seu sistema de construção exigirá um mecanismo para configurar um ambiente adequadamente definido no qual criar e validar seus componentes de origem. + +Para construir um componente a partir do código-fonte, precisamos reunir todas as dependências nas quais esse componente depende, realizar qualquer configuração necessária para o ambiente de destino e, no caso de linguagens compiladas, realizar a compilação propriamente dita. + +Isso nos leva a um dos problemas mais difíceis na computação, a gerência de dependências. Uma determinada versão do seu código espera uma versão específica de cada biblioteca, componente compartilhado, serviço externo ou recurso do sistema operacional no qual ele depende. Todos esses componentes têm seus próprios ciclos de vida, a maioria dos quais estará fora do seu controle direto. + +Se você não especificar explicitamente qual versão de uma dependência é necessária para construir seu código, então seu sistema deixará de ser construível ao longo do tempo, pois alterações externas na versão mais recente de uma biblioteca introduzem incompatibilidades não antecipadas. + +Se você especificar explicitamente qual versão de uma dependência é necessária para construir seu código, então seu sistema ficará preso no tempo, significando que ele se afastará cada vez mais da funcionalidade fornecida pelas dependências mantidas. Isso incluirá patches de segurança e suporte para novas versões do sistema operacional, por exemplo. + +Além disso, dependendo da forma como sua aplicação é implantada, muitas dessas dependências podem ser compartilhadas entre vários componentes em seu sistema, ou entre seu sistema e outras aplicações associadas no mesmo ambiente. Isso pode levar a pesadelos de compatibilidade em tempo de execução para os clientes. Você também deve considerar que pode precisar ser capaz de executar várias versões de seus próprios componentes em paralelo na produção, o que novamente introduz o risco de incompatibilidade entre bibliotecas ou serviços compartilhados. Por um bom motivo, isso geralmente é conhecido como 'inferno das dependências' e pode facilmente destruir um produto através de atrasos não antecipados, erros e má experiência do cliente. + +A implicação disso é que você deve empregar um mecanismo para permitir o gerenciamento controlado de dependências em todos os componentes do seu produto e um processo para exigir atualizações contínuas e incrementais para rastrear os ciclos de vida de suas dependências, caso contrário, seu produto sucumbirá à 'degradação' à medida que se afasta cada vez mais dos ambientes de seus clientes. + +Decompor seu produto em serviços fracamente acoplados que podem ser implantados em contêineres independentes se comunicando por meio de APIs publicadas fornece controle máximo sobre problemas de dependência em tempo de execução. + +O restante de nossas perguntas nos leva ao tema dos testes. + +Para verificar se um componente se comporta como seu desenvolvedor esperava, nosso sistema de construção deve ser capaz de executar um conjunto de testes fornecido pelo desenvolvedor. Isso deve ser considerado como uma forma de 'falhar rapidamente' para descobrir se o código não está se comportando da mesma maneira que quando foi desenvolvido e representa uma forma de teste de regressão contra o impacto de modificações futuras na base de código em questão. No entanto, observe que tanto o código quanto os testes incorporam o mesmo conjunto de pressupostos feitos pelo desenvolvedor original, portanto, são insuficientes para provar a correção do componente no contexto do produto. + +Nesta fase, é recomendável realizar uma análise do código para estabelecer vários indicadores de qualidade e conformidade com padrões internos. Isso pode ser na forma de análise automatizada de qualidade de código, análise de segurança, análise de privacidade, verificação de dependências, verificação de licenças, etc., e na forma de aplicação automatizada de processos de revisão por pares manuais. + +Para verificar se um componente se comporta como outros desenvolvedores, que estão consumindo serviços fornecidos pelo componente, esperam, devemos integrar esses componentes e testar o comportamento do sistema contra seus pressupostos combinados. O objetivo deste teste é garantir que os componentes atendam ao contrato declarado de comportamento e destacar áreas onde este contrato é insuficientemente preciso para permitir o desacoplamento eficaz entre as equipes. + +O conjunto final de testes valida se o produto montado faz o que é esperado. Isso geralmente envolve a criação de um ambiente que seja um fac-símile razoável do seu ambiente de produção e testar as capacidades de ponta a ponta em relação aos requisitos. + +Coletivamente, essas atividades são conhecidas como Integração Contínua quando realizadas automaticamente como um processo acionado pela inclusão de código nos repositórios de controle de código-fonte do produto. Este é um tópico ao qual retornaremos com mais detalhes nos capítulos posteriores. + +Essas atividades fornecem uma visão unificada do status dos ativos, da dívida técnica e da degradação ao longo do tempo da propriedade intelectual. Para a maioria de uma equipe de produto, elas serão o único mecanismo pelo qual a equipe tem visibilidade do progresso e, como tal, deve ser possível para qualquer membro da equipe iniciar testes e observar os resultados, independentemente de suas habilidades técnicas. + +No entanto, em última análise, suas equipes devem assumir a responsabilidade direta pela qualidade, segurança e privacidade. Adotar um processo padrão e rastreável de revisão por pares para todas as alterações de código proporciona múltiplos benefícios. Muitos olhos sobre um problema ajudam a detectar erros, mas também se tornam parte integrante do ciclo de comunicação dentro da equipe que ajuda os outros a entender no que cada um está trabalhando e como a solução se encaixa para atender aos requisitos. Feito corretamente e com sensibilidade, também se torna um mecanismo eficaz para orientar e elevar os membros menos experientes de uma equipe a níveis eficazes de produtividade e qualidade. + +Seu sistema de construção deve fornecer total rastreabilidade para que você possa ter confiança de que o código que foi submetido a análise estática e revisão por pares é o mesmo código que está passando pelo processo de construção e está livre de adulterações. + +A saída desejada desta etapa na fabricação do seu produto é ter ativos construídos que possam ser implantados. Anteriormente, isso teria sido executáveis, pacotes ou arquivos de distribuição prontos para serem implantados, mas sob DevOps, estamos tipicamente buscando criar ambientes contêinerizados contendo o produto, pré-configurados. + +Isso deve ser um processo automatizado que aproveita as informações de configuração específicas do ambiente mantidas no repositório de código-fonte com o código que descreve o ambiente de destino desejado para implantação. Essas informações são usadas para criar uma imagem de contêiner que contém os executáveis do seu produto, configuração padrão, dados e todas as dependências. + +Nesta etapa do processo, é apropriado aplicar aprimoramento automatizado de infraestrutura e testes de penetração contra sua imagem de contêiner para garantir um perfil de segurança conhecido. + +A imagem pode então ser publicada em um repositório de imagens, onde representa um ativo versionado pronto para implantação. Este repositório facilita a reutilização eficiente de ativos e fornece uma série de benefícios, incluindo: + +* Capacidade de implantar imagens de contêiner idênticas conhecidas em ambientes de teste e produção +* Simplificar a reutilização de instâncias de serviços contêinerizados em vários produtos +* Facilitar a criação de instâncias independentes para novos clientes em ambientes de produção isolados +* Possibilitar o gerenciamento de várias versões de um produto em múltiplos ambientes, incluindo a capacidade de retroceder rapidamente para uma versão conhecida como boa após uma implantação mal sucedida. + +Como uma observação adicional ao processo, é aconselhável configurar compilações programadas do seu produto, puramente para agir como validação automatizada do status de saúde do seu ativo. Isso proporciona confiança contra 'degradação' devido a fatores externos não antecipados, como mudanças na árvore de dependências ou no ambiente de construção que introduzem falhas de compilação. Paralelamente a isso, você deve planejar atividades regulares de manutenção para atualizar sua base de código para refletir as mudanças nas dependências externas ao longo do tempo, para que seu ativo não se torne obsoleto e o deixe incapaz de reagir rapidamente a eventos de emergência, como explorações de dia zero que devem ser corrigidas imediatamente. + +Ter uma máquina que pode construir seu produto é apenas metade da resposta, no entanto. Muito do risco está dentro do processo de implantar o produto em produção e isso também deve ser automatizado para mitigar com sucesso os principais problemas nesse espaço. + +O primeiro problema é 'o que implantar?'. Você tem um repositório de ativos se enchendo com coisas teoricamente implantáveis, mas há um problema sutil. Dependendo da maneira como você mede e recompensa suas equipes de desenvolvimento, as compilações que entram em seu repositório podem ser unidades viáveis de código que passam nos testes, mas que não representam recursos prontos para o cliente que são seguros para serem ativados. Na maioria das equipes novas, é justo esperar que este seja o estado padrão das coisas, mas este é um padrão anti-clássico. + +Para perceber muitos dos benefícios do DevOps, é essencial que as imagens que entram no seu repositório de ativos estejam prontas para produção, não apenas 'eu terminei minha parte' prontas do ponto de vista do desenvolvedor. Você precisa criar uma cultura na qual a definição de concluído mude de 'Eu terminei de hackear o código' para 'Todo o código, configuração e infraestrutura é testado e o recurso está em execução na produção'. + +Não é sempre fácil chegar a esse ponto, especialmente com recursos complexos e equipes grandes, mas há uma solução alternativa que permite que você adie o problema um pouco e isso é a adoção de comutação de recursos, ou 'flags de recursos'. Usando este método, você envolve todo o código associado ao seu novo recurso em declarações condicionais que podem ser ativadas ou desativadas em tempo de execução usando configuração. Você testa seu código com as declarações ligadas e desligadas para garantir que ambos os cenários sejam seguros e cria um ativo que pode ser implantado em qualquer estado. Nessas circunstâncias, você está protegido de situações em que o código depende de outro serviço que atrasou na sua data de entrega, então seu ativo ainda está pronto para produção com o novo recurso desligado. Você também está protegido de falhas não antecipadas no novo recurso, pois pode desativá-lo na produção ou realizar testes comparativos na produção ativando o recurso apenas para alguns clientes. + +Dado isso, o próximo problema é 'quando implantar?'. Em algum momento, você precisa tomar uma decisão de prosseguir / não prosseguir contra a implantação de um novo ativo. Isso deve ser baseado em um processo de implantação consistente, auditado e automatizado o máximo possível. + +Em ambientes críticos de segurança, como aeronaves ou salas de operação, listas de verificação são usadas para garantir que as ações corretas sejam tomadas em qualquer cenário, especialmente quando há pressão para responder urgentemente a problemas imediatos. Tripulações de voo e equipes de teatro são treinadas no uso de listas de verificação para minimizar as chances de pular atividades essenciais quando distraídas por circunstâncias. Seu sistema de construção de produto deve automatizar o máximo possível dessas atividades de lista de verificação para garantir que as principais ações aconteçam toda vez que você fizer um lançamento. + +Este também é um bom lugar para automatizar suas tarefas de conformidade regulatória para que você possa sempre associar atividades de conformidade mandatórias a um lançamento auditado. + +A decisão de implantação deve ser gerenciada sob controle de acesso baseado em funções, com apenas indivíduos nomeados autorizados a iniciar uma implantação. Lembre-se de que se alguém conseguir violar o sistema que constrói seu produto, eles podem injetar código malicioso em seu repositório de ativos manipulando seus testes, então você deve tomar precauções para garantir que existam motivos claros para o novo código ser aprovado para produção. + +Isso nos leva ao 'o quê, especificamente?' da implantação. Os ativos em seu repositório são tipicamente serviços reutilizáveis que são agrupados com configurações padrão que foram usadas para teste, mas agora você precisa de uma instância concreta deste serviço, em um ambiente específico, contra um conjunto específico de outras instâncias de serviço, para um cliente ou aplicação específicos. Portanto, seu processo de implantação deve incluir um conjunto apropriado de substituições de configuração que definirão a instância específica que está sendo criada. Aqui é onde você deve lidar com o recurso de comutação que você adiou anteriormente. + +Finalmente, chegamos ao 'como?' da implantação. Idealmente, você deseja um processo de implantação intocado por mãos humanas, para garantir um processo previsível e repetível com resultados conhecidos. Você pode usar scripts procedimentais para implantar seu ativo, mas geralmente é melhor usar uma abordagem declarativa, como o GitOps, onde você mantém uma descrição versionada de como deseja que seu ambiente de produção seja e as mudanças comprometidas com essa descrição acionam o sistema para fazer o que for necessário para alinhar o ambiente de produção com o estado desejado. +Lembre-se do modelo de 'animais de estimação versus gado' de ambientes. Se você tiver um problema com a infraestrutura, é muito melhor matar a instância e criar uma nova automaticamente do que tentar ajustá-la manualmente para torná-la saudável novamente. + +Como parte deste processo, você desejará ter validação automatizada de implantação bem-sucedida e recuperação automatizada para o último estado conhecido bom no caso de uma falha. + +Você está tentando criar uma cultura e um mecanismo no qual pequenas unidades de funcionalidade são implantadas incrementalmente na produção com a menor quantidade possível de entrada humana. Isso é Implantação Contínua. + +Ao unir tudo isso, seu objetivo é construir um mecanismo de entrega de produto que permita a Entrega Contínua de recursos que apoiem os objetivos de descoberta de produto, em uma cadência alinhada às métricas discutidas anteriormente, maximizando assim suas chances de sucesso comercial dentro das restrições de sua capacidade e espaço disponíveis. + +Nas seções subsequentes, exploraremos mais detalhadamente os aspectos específicos de cada um desses desafios. \ No newline at end of file diff --git a/content/pt/learn/overview/problem.md b/content/pt/learn/overview/problem.md new file mode 100644 index 0000000..b90b81a --- /dev/null +++ b/content/pt/learn/overview/problem.md @@ -0,0 +1,130 @@ +--- +title: "Compreendendo o Problema" +linkTitle: "Compreendendo o Problema" +weight: 1 +author: Terry Cox +description: > + Conheça os desafios fundamentais que a Entrega Contínua aborda +--- + +{{% youtube RC5Ai0buX3Y %}} + +
+O desenvolvimento de software em escala é uma atividade dentro do contexto mais amplo da Comercialização de Produtos. + +> Nosso objetivo não é construir software, mas sim construir um produto que aproveite o software ou aprendizado de máquina para resolver o problema que o produto aborda. + +Os problemas da comercialização de produtos direcionam a abordagem que usamos para otimizar a entrega de software. Vamos começar entendendo esses problemas. + +É frequentemente assumido que o desenvolvimento de produtos parece assim: + +1. Ter uma ideia brilhante para um produto +2. Construir o produto acabado +3. Vender o produto +4. Lucrar! + +Na prática, a realidade é que sua ideia na verdade é uma suposição sobre o que poderia representar um produto, mas nessa fase, você não tem evidências para mostrar que alguém deseja comprá-lo. + +Você poderia seguir o fluxo acima, mas se você for investir, digamos, $10M no processo de desenvolvimento do seu produto, você está efetivamente apostando esses $10M na chance de que haverá clientes suficientes para recuperar seu investimento e obter lucro. + +A melhor prática na comercialização de produtos se parece mais com isso: + +1. Ter 1.000 ideias +2. Avaliar e classificar cada ideia quanto ao mérito potencial para encontrar a melhor +3. Pegar essa ideia e encontrar um punhado de clientes que tenham o problema que ela resolve +4. Trabalhar iterativamente com seus clientes para construir uma série de experimentos que testem a utilidade de sua ideia na escala mínima viável +5. Se seus clientes se empolgarem e começarem a oferecer dinheiro pelo produto, investir na escalabilidade para uma implementação completa; caso contrário +6. Parar. Escolher a próxima ideia da sua lista e voltar ao passo 3 + +Isso garante que você só está investindo pesadamente em atividades que têm evidências sólidas de ajuste de mercado do produto. + +O problema é que, mesmo com esse processo, menos de uma em dez ideias de produto terá sucesso no mercado, então é muito importante otimizar esse processo para funcionar o mais enxuto possível, de modo que o custo de executar seus experimentos de aprendizado seja gerenciável dentro das reservas de investimento disponíveis para você. + +O que isso significa do ponto de vista do desenvolvimento de software? + +Bem, no primeiro modelo, você espera receber um conjunto completo de requisitos de antemão e poderia otimizar cuidadosamente um design levando em consideração tudo o que o produto precisa ser capaz de fazer. Então isso poderia ser decomposto em recursos e dados às equipes para implementar de acordo com as especificações. + +No modelo enxuto, tudo o que você tem para começar são suposições sobre qual pode ser o problema do cliente. Nesse caso, o papel da equipe de desenvolvimento na verdade é ajudar a projetar e construir experimentos que validem (ou invalidem) cada suposição, em conjunto com clientes reais. + +No primeiro modelo, você espera passar cerca de um ano cometendo erros e aprendendo sobre o domínio do problema em privado, antes de um grande lançamento público de um aplicativo polido. + +No modelo enxuto, você precisa aprender na frente do cliente, entregando regularmente novos recursos experimentais em ambientes de produção ao vivo. + +Esse aprendizado assume a forma de um ciclo iterativo: + +1. Propor uma hipótese sobre qual recurso pode ser de valor para o cliente +2. Projetar e desenvolver um experimento para testar esse recurso no ambiente do cliente +3. Executar o experimento com o cliente e avaliar +4. Ajustar o experimento e reexecutar; ou +5. Passar para o próximo experimento; ou +6. Encerrar o produto + +É claro que você pode esperar ter um orçamento finito para investir em experimentos de aprendizado, e seus clientes terão uma atenção finita, então há um limite rígido de quantas vezes você pode iterar por esse ciclo antes de falhar. Como resultado, é crucial otimizar esse ciclo para poder arcar com o máximo de iterações possível para maximizar sua chance de descobrir um conjunto de recursos que demonstre ajuste de mercado do produto. + +Isso significa que podemos derivar duas métricas críticas que nos ajudarão a manter o foco na otimização do nosso processo de comercialização de produtos o tempo todo: + +## Frequência de Implementação +Sua capacidade de executar o ciclo acima é limitada pela frequência com que você pode implantar seu produto em produção. Se levar seis meses para mover um recurso para produção, você ficará sem dinheiro e clientes muito antes de poder executar mais do que aquele único experimento. Se levar uma semana para implantar, você provavelmente não poderá executar experimentos suficientes para descobrir o produto certo. + +Isso implica a necessidade de otimizar todo o processo de entrega para ser capaz de mover recursos para produção em um ritmo de dias a horas. + + +## Lead Time +Compreender o tempo decorrido desde o momento de identificar uma nova hipótese que se deseja testar até o momento em que um experimento para testá-la é implantado em produção ajuda a definir a granularidade dos experimentos que você pode realizar. Se uma equipe levará três meses para implementar um experimento, deve-se considerar a redução do escopo do experimento ou dividir o problema em componentes menores que possam ser desenvolvidos em paralelo por várias equipes de recursos. + +A otimização do processo de entrega para consistentemente reduzir os tempos de liderança aumenta a capacidade de realizar mais iterações experimentais dentro do seu espaço de manobra disponível. + +Trabalhar dessa forma iterativa requer uma mudança conceitual fundamental em todas as equipes de entrega. Em vez da suposição de que "o produto deve ser perfeito, eventualmente", é necessário assumir que a falha é esperada regularmente e, como resultado, ser principalmente muito bom em corrigir as coisas rapidamente. + +Isso não deve ser interpretado como 'a qualidade é menor'. Realisticamente, a ideia de construir produtos que não quebrem é uma simplificação ingênua. Em vez disso, devemos considerar que as coisas podem quebrar; devemos antecipar as maneiras pelas quais elas podem ser esperadas para quebrar e mitigar o risco associado a falhas. + +Uma quebra não antecipada que derruba um produto por uma semana pode acabar com um negócio. Uma interrupção temporária de um recurso de um produto é apenas uma pequena irritação e uma implantação de recurso falhada que é revertida com segurança após a falha nos testes preliminares provavelmente passará despercebida. + +Isso nos permite derivar mais duas métricas-chave: + +## Tempo para Restaurar +Otimizar o tempo entre identificar um incidente e se recuperar dele mitiga a exposição ao risco durante a falha. Tipicamente, isso nos incentiva a decompor nossos designs em componentes de pequena escala que são facilmente testáveis e têm impacto limitado no caso de falha. Onde são cometidos erros, limitar o alcance do impacto desses erros reduz o risco e o tempo necessário para se recuperar. + +## Taxa de Falha de Mudança +Rastrear a porcentagem de mudanças que levam a um incidente em produção nos dá uma métrica proxy para qualidade. Isso deve, por sua vez, levar a uma análise apropriada da causa raiz. Se muitas das mudanças que fazemos em nosso produto estão causando problemas, nós realmente entendemos o problema para o qual nosso produto foi projetado? A equipe de desenvolvimento de produtos entende o produto que está construindo? Nosso processo de entrega é propenso a erros? + +Por que esse foco em métricas, no entanto? + +Bem, este é outro grande desafio para o desenvolvimento de produtos de tecnologia. +Em disciplinas de engenharia tradicionais, como engenharia civil ou aeroespacial, você está construindo algo físico. Se, todos os dias, seu produto em desenvolvimento se parece mais com uma ponte ou um avião, todos na equipe podem entender que você está indo na direção certa e ter uma ideia do progresso. Se seu avião começa a se parecer mais com um elefante, você pode parar e reavaliar suas atividades para garantir que esteja no caminho certo. + +Agora, imagine que você está construindo uma aeronave invisível composta por milhares de componentes invisíveis. + +Você não pode ver os componentes sendo construídos, nem o produto sendo montado a partir deles. Você tem uma equipe de centenas de pessoas trabalhando no produto e está confiando inteiramente na fé cega de que todos sabem o que estão fazendo e estão construindo partes compatíveis, porque a primeira vez que você poderá evidenciar isso será no voo inaugural com o cliente... + +Certamente, ninguém em sã consciência compraria uma aeronave de uma empresa que tivesse um processo de engenharia assim, certo? + +Claro, a realidade é que é exatamente assim que muitas organizações abordam o desenvolvimento de produtos de software e isso explica em grande parte por que 70% dos projetos de software falham e 20% desses falham tão mal a ponto de ameaçar a viabilidade da empresa-mãe. + +Um componente fundamental da entrega bem-sucedida de software reside em tornar o progresso visível dentro de um domínio intrinsecamente invisível. + +Pequenas equipes tendem a fazer isso naturalmente usando comunicação. Muitas adotam rituais básicos ágeis que envolvem stand-ups diários para comunicar problemas, progressos e obstáculos. Em pequena escala, isso é viável. No entanto, o número de possíveis caminhos de comunicação escala com n2-n (onde n é o número de pessoas na equipe). Como resultado, uma vez que você ultrapassa cerca de seis pessoas em uma equipe, elas passam a maior parte do tempo em atividades de comunicação em vez de desenvolver software. + +A implicação disso é que, para produtos maiores, é insuficiente seguir nossos instintos naturais ou aplicar técnicas básicas de gerenciamento de projetos de engenharia de outras disciplinas. Precisamos aplicar uma metodologia especificamente projetada para mitigar os riscos associados ao trabalho com ativos intangíveis. + +Antes de analisarmos os detalhes de tal metodologia, devemos primeiro considerar o valor de um ativo de software de uma perspectiva comercial, em vez de puramente técnica. O software que criamos pode ser considerado uma ferramenta projetada para resolver um problema específico do mundo real e o valor dessa ferramenta está relacionado ao benefício gerado para o cliente pela resolução de seu problema. + +Isso é importante porque é raro que o software tenha valor intrínseco e de longo prazo. O software existe como uma solução transitória para problemas contemporâneos no mundo exterior. Onde uma commodity como o ouro tem um valor flutuante, mas efetivamente perpétuo no mercado, o valor do software depende inteiramente de fatores externos, como a continuidade da existência do problema que um determinado programa foi projetado para resolver e o fato de que esse software ainda representa a melhor solução disponível para esse problema. + +Como o software é implicitamente impactado por fatores externos, ele deve ser considerado como um ativo perecível. O problema para o qual seu software é projetado enfrenta mudanças lentas ao longo do tempo. O mercado em que seu software compete muda bastante rapidamente. O hardware físico e o sistema operacional em que seu software opera evoluem continuamente. O ambiente legislativo e de conformidade impacta as mudanças em seu software, assim como os desafios de segurança e proteção de dados associados. + +Portanto, é crítico entender que o software se degrada se ficar intocado por qualquer período de tempo. + +Se pensarmos no software em uma base centrada em projetos, cometemos o erro de considerá-lo como um processo linear, desde o design até o lançamento, e então tentamos otimizar nosso processo para chegar à 'linha de chegada' mais rapidamente. + +Para gerenciar adequadamente os ativos de software, eles devem ser considerados no contexto de um ciclo de gerenciamento de ativos contínuo e iterativo, onde 'lançamento' é meramente uma etapa regular e repetitiva no ciclo de vida do ativo. + +Vale a pena reiterar aqui que o valor do software é baseado no que ele realmente pode fazer pelos clientes, não no que acreditamos que pode fazer. Se esse valor pode mudar ao longo do tempo devido a fatores externos e o próprio ativo é efetivamente invisível e, portanto, não pode ser observado diretamente, precisamos de algum mecanismo pelo qual possamos avaliar confiavelmente o valor contínuo do ativo que possuímos. + +Este problema é fractal por natureza, já que se repete em vários níveis dentro de nossa aplicação. Um produto de software é tipicamente composto por vários componentes ou recursos, os quais, ao operar em escala, quase sempre são desenvolvidos e mantidos por equipes diferentes. Esses componentes são construídos sobre outros componentes, frequentemente de equipes fora da sua organização, e assim por diante, até o microcódigo nos processadores em que você está executando. + +Cada um desses componentes deve ser considerado parcialmente completo. Eles alcançam alguns de seus objetivos de design, mas têm algum nível de dívida técnica associada que não foi quitada porque não é economicamente viável fazê-lo completamente, ou porque você está fazendo algo com ele que os proprietários ainda não tiveram tempo para testar. + +Portanto, tudo em seu ativo é construído com base em coisas que estão potencialmente um pouco quebradas ou prestes a quebrar devido a fatores fora de sua consciência. + +Não há uma "solução permanente" para este problema que possa ser aplicada uma vez e esquecida. A única abordagem viável é reconstruir repetidamente sua aplicação a partir de todos os seus componentes para garantir que ainda possa ser construída e testar repetidamente o ativo para medir se ainda está atendendo aos fatores que lhe conferem valor no mercado. Na próxima seção, vamos examinar com mais detalhes os métodos de melhores práticas para alcançar isso de forma eficaz e confiável. \ No newline at end of file diff --git a/content/pt/learn/overview/risks.md b/content/pt/learn/overview/risks.md new file mode 100644 index 0000000..7c9d1bb --- /dev/null +++ b/content/pt/learn/overview/risks.md @@ -0,0 +1,32 @@ +--- +title: "Erros Comuns" +linkTitle: "Erros Comuns" +weight: 10 +author: Terry Cox +description: >- + "Como ser realmente bom em Entrega Contínua E destruir completamente sua empresa" +--- + +Antes de irmos mais a fundo, é muito importante destacarmos um anti-padrão comum que pode levar sua experiência de Entrega Contínua para uma direção catastrófica. + +Nós introduzimos a ideia de DevOps como um processo que ajuda você a otimizar entrega com base em métricas. Escolha as métricas erradas, no entanto, e você se tornará muito eficiente em estar ocupado fazendo todas as coisas erradas até ficar sem recursos e ser desligado. + +É muito tentador alinhar todas as suas métricas com a entrega de recursos. Todos na organização participarão felizes dessa atividade porque os recursos são listas arbitrárias de trabalho que são fáceis de criar, fáceis de medir o progresso contra e geralmente representam coisas que estão diretamente ligadas a marcos e bônus. Pior ainda, é realmente muito fácil construir processos que automatizem o pipeline de ponta a ponta da entrega de recursos e mensuração da entrega deles. Você se sentirá bem fazendo isso. Todos estarão ocupados. Coisas acontecerão e recursos serão entregues. As coisas estarão acontecendo mais rápido e de forma mais eficiente do que antes. Bônus e incentivos serão abundantes. + +Então, haverá um ajuste de realidade. Seus clientes ainda não estão felizes. Ninguém está comprando. Na verdade, a instrumentação mostra que ninguém está realmente usando os recursos que você enviou. O crescimento estagna e todos começam a dizer que "Entrega Contínua não funciona". + +Aqui está o erro: Recursos são resultados. **Para a Entrega Contínua funcionar conforme o pretendido, suas métricas devem ser baseadas em Resultados, não em Resultados de Saída.** + +> Os benefícios da Entrega Contínua **não** são derivados da otimização do processo de engenharia dentro de sua organização. O objetivo da Entrega Contínua é otimizar a entrega desses resultados que são mais importantes para seus clientes. + +A maior parte dos detalhes técnicos da implementação da Entrega Contínua pode parecer estar dentro da função de engenharia e as transformações do DevOps muitas vezes são lideradas por essa equipe, mas a Entrega Contínua só funcionará para sua organização se for adotada como um componente central de uma estratégia de comercialização de produtos que alinhe todas as atividades entre acionistas, gerência, marketing, vendas, engenharia e operações. + +As atividades que fluem por seu pipeline de Entrega Contínua devem ser experimentos para validar uma hipótese sobre as necessidades do cliente, ou a entrega de recursos que representam uma necessidade de cliente previamente validada. Tudo isso deve ser impulsionado pela interação direta com o cliente. + +Para implementar com sucesso a Entrega Contínua, sua organização deve ter uma estrutura que estabeleça resultados estratégicos e capacite equipes a descobrir as necessidades dos clientes e levar soluções a eles ao mercado. Isso implica um nível de conforto com a incerteza e uma confiança nas equipes de entrega para fazer o que é melhor para o cliente no contexto da estratégia. + +Em um negócio clássico, 'estratégia' é pouco mais do que um plano de trabalho que é formado anualmente e que descreve o conjunto de recursos a serem entregues no ano seguinte. Todos os gastos e bônus são estruturados contra esse plano, deixando pouco espaço para mudar qualquer coisa sem 'falhar' no plano. + +Se uma equipe de engenharia tentar implementar a Entrega Contínua unilateralmente dentro dessa estrutura, eles se encontrarão pressionados a usá-la para implementar recursos planejados pelo restante da organização. Além disso, eles não terão poder para lançar em produção porque os processos de lançamento permanecerão definidos por outras áreas do negócio que ainda estão operando contra incentivos e prazos clássicos. + +Amplo apoio à mudança organizacional no nível do conselho é necessário para uma implementação bem-sucedida da Entrega Contínua. \ No newline at end of file diff --git a/docker-compose.yaml b/docker-compose.yaml index 608144c..0773414 100644 --- a/docker-compose.yaml +++ b/docker-compose.yaml @@ -3,11 +3,9 @@ version: "3.3" services: site: - image: docsy/cdf-best-practices - build: - context: . - command: server + image: klakegg/hugo:ext-alpine ports: - "1313:1313" volumes: - .:/src + command: ["server", "--bind", "0.0.0.0"] diff --git a/hugo.toml b/hugo.toml index a08a620..d26963a 100644 --- a/hugo.toml +++ b/hugo.toml @@ -10,7 +10,7 @@ enableGitInfo = true defaultContentLanguage = "en" defaultContentLanguageInSubdir = false # Useful when translating. -# enableMissingTranslationPlaceholders = true +enableMissingTranslationPlaceholders = true # Comment out to disable taxonomies in Docsy # disableKinds = ["taxonomy", "taxonomyTerm"] @@ -72,6 +72,15 @@ id = "UA-00000000-0" weight = 2 [languages.es.params] description = "Prácticas Recomendadas de CD Foundation para la Entrega Continua" + + [languages.pt] + contentDir = "content/pt" + title = "Melhores Práticas" + languageName = "Portuguese" + # Weight used for sorting. + weight = 3 + [languages.pt.params] + description = "Melhores Práticas da CD Foundation para Entrega Contínua" # Languages sectiopn MUST come before this! # Declare and configure Docsy theme.