initial commit pt-br translation

.gitignore

@@ -1,5 +1,6 @@
 node_modules/
 /resources/
+public/
 
 # vim temporary files
 *~

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

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" >}}
+<div class="mx-auto">
+	<a class="btn btn-lg btn-primary mr-3 mb-4" href="{{< relref "/learn/overview" >}}">
+		Saiba Mais <i class="fas fa-arrow-alt-circle-right ml-2"></i>
+	</a>
+</div>
+
+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 >}}

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.

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
+---

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.