Translations

• 1: Deutsch
• 2: Español
• 3: Francais
• 3.1: Au-delà des minimums
• 4: Italiano
• 4.1: Domande Frequenti (FAQ)
• 5: Português
• 6: Português Brasileiro
• 7: Sinhala
• 8: Suomi
• 9: Texan

1 - Deutsch

Wir, die Unterzeichner, sind der Meinung, dass eine Minimale Definition von Continuous Delivery (CD) erforderlich ist, um den Ablauf der Software-Lieferung zu verbessern und die oben genannten Ergebnisse zu erzielen. Obwohl unsere Kontexte unterschiedlich sein mögen, gibt es universelle Praktiken, die allen Situationen und Teams gemeinsam sind. Indem wir diese definieren, können wir:

• neue Praktiker auf konsistente Art und Weise einführen
• die technischen Praktiken, die CD ausmachen, diskutieren
• uns gegenseitig helfen, unsere derzeitigen Fähigkeiten zu verbessern

Nur wenn wir Kernpraktiken umsetzen, können wir die Vorteile von Continuous Delivery für uns nutzen.

Die untenstehenden Praktiken sind das Minimum, ein Ausgangspunkt. Das erwartete Ergebnis ist eine kontinuierliche Verbesserung der Geschwindigkeit, Qualität und Sicherheit der Lieferpipeline.

Kontinuierliche Lieferung

Kontinuierliche Lieferung (Continuous Delivery, CD) ist die technische Disziplin, bei der alle Änderungen auf sichere Weise in einem stets gleichen Verfahren bereitgestellt werden. CD deckt ein breites Spektrum von Aktivitäten ab, je nach den Besonderheiten des Liefergegenstandes. Es gibt jedoch bestimmte Verhaltensweisen und Fähigkeiten, die in jedem Kontext erfüllt sein müssen, um als “kontinuierliche Lieferung” zu gelten.

Die für CD erforderlichen Mindestaktivitäten sind:

• Kontinuierliche Integration verwenden
• Die Anwendungspipeline ist die einzige Möglichkeit zur Lieferung in einer beliebigen Umgebung.
• Die Pipeline entscheidet über die Freigabefähigkeit von Änderungen, ihr Urteil ist endgültig
• Die von der Pipeline erstellten Artefakte entsprechen immer der der organisationseigenen “Definition für deploybar”.
• Unveränderliche Artefakte. Keine menschlichen Änderungen nach der Übergabe an cas CD-System.
• Jegliche Arbeiten an Features werden eingestellt, wenn die Pipeline defekt ist.
• Produktionsähnliche Testumgebung
• Rollback bei Bedarf
• Anwendungskonfiguration wird gemeinsam mit dem Artefakt ausgeliefert

Kontinuierliche Integration

Bei der kontinuierlichen Integration (continuous integration, CI) wird die Arbeit sehr häufig in den Stamm (trunk) der Versionskontrolle integriert und überprüft, ob die Arbeit nach bestem Wissen und Gewissen freigegeben werden kann.

Die für CI erforderlichen Mindestaktivitäten sind:

• Trunk-basierte Entwicklung
• Die Arbeit wird mindestens täglich in den Stamm integriert
• Die Arbeit wird vor dem Zusammenführen mit dem Trunk automatisch getestet.
• Die Arbeit wird beim Merge automatisch mit anderen Arbeiten getestet
• Alle Arbeiten an Features werden gestoppt, wenn der Build defekt ist.
• Neue Arbeiten machen die bereits gelieferten Arbeiten nicht kaputt

Trunk-basierte Entwicklung

Die trunk-basierte Entwicklung ist das branching Modell, das erforderlich ist, um die Definition von CI zu erfüllen. Es verhindert den Verlust von Arbeit, das Risiko von verfälschtem oder defektem Code bei der Lösung von Merge-Konflikten besteht und auch die (Lean-) Verschwendung durch Bewegung, die die Batchgröße erhöht.

• Die für TBD erforderlichen Mindestaktivitäten sind:
  • Alle Änderungen werden in den Stamm integriert.
  • Wenn Zweige aus dem Stamm verwendet werden:
    • Sie stammen aus dem Stamm
    • Sie werden wieder in den Stamm integriert
    • Sie sind kurzlebig und werden nach dem Merge entfernt.

Warum haben wir das gebaut?

Für Hintergrundinformationen zu Minimum CD und Antworten auf andere häufige Fragen, lesen Sie bitte die FAQs.

Die Reise beginnen

Haben Sie Fragen, wo Sie anfangen sollen? Sehen Sie sich einige Empfehlungen an.

Beitragen

Möchten Sie eine Übersetzung, Best Practices, Vorschläge oder einen Erfahrungsbericht einreichen?

Lesen Sie unsere Richtlinien für Beiträge

Mitwirkende

Unterzeichner

2 - Español

Entrega Continua Mínima Viable

Nosotros, los abajo firmantes, creemos que se requiere una definición mínima de entrega continua (CD por sus siglas en inglés) para mejorar el flujo de entrega y lograr los resultados anteriores. Si bien nuestros contextos pueden ser diferentes, existen prácticas universales. Al definirlos podemos:

• Introducir a los nuevos profesionales de forma coherente
• Discutir las prácticas de ingeniería que abarca CD
• Ayudarnos mutuamente a mejorar las capacidades actuales

Solo mediante la implementación de prácticas básicas comenzamos a ver los beneficios de la entrega continua.

Las prácticas mencionadas a continuación son el mínimo, un punto de partida. La mejora continua de la velocidad, calidad y seguridad del pipeline de entrega es el resultado esperado.

Entrega Continua

CD es la disciplina de ingeniería que consiste en realizar todos los cambios de manera estándar y segura. Cubre un amplio espectro de actividades dependiendo de lo que se esté entregando. Sin embargo, hay comportamientos y habilidades que deben cumplirse en todos los contextos para calificar como “entrega continua”.

Las actividades mínimas requeridas para CD son:

• Integración continua.
• El pipeline de la aplicación es el único camino para desplegar en producción.
• El pipeline decide la posibilidad de entrega de los cambios, el veredicto es definitivo.
• Los artefactos creados por el pipeline siempre cumplen los requisitos de definición de desplegable de la organización.
• Artefacto inalterable. No hay cambios hechos por personas después de la confirmación.
• Todo el trabajo de funcionalidades se detiene cuando el pipeline está en rojo
• Entorno de prueba similar a producción
• Revertir bajo demanda.
• La configuración de la aplicación se despliega con el artefacto.

Integración Continua

Integración continua (CI por sus siglas en inglés) es la actividad de integrar muy frecuentemente el trabajo a la rama principal del control de versiones y verificar que el trabajo sea, según nuestro leal saber y entender, entregable.

Las actividades mínimas requeridas para CI son:

• Desarrollo basado en rama principal
• El trabajo se integra a la rama principal como mínimo cada día
• El trabajo tiene pruebas automatizadas antes de fusionarse con la rama principal
• El trabajo se prueba con otro trabajo automáticamente al fusionarse
• Todo el trabajo de funcionalidades se detiene cuando el construcción está en rojo
• El trabajo nuevo no rompe el trabajo entregado

Desarrollo Basado en Rama Principal

Desarrollo Basado en Rama Principal (TBD por sus siglas en inglés) es el patrón de ramificación requerido para cumplir con la definición de CI. Previene el trabajo perdido, el riesgo de corrupción que proviene de la resolución de conflictos fusionados, y también reduce el desperdicio de movimiento que incrementan el volumen de cambios.

• Las actividades mínimas requeridas para TBD son:
  • Todos los cambios se integran en la rama principal
  • Si se utilizan ramas desde la rama principal:
    • Se originan en la rama principal
    • Se reintegran la rama principal
    • Son de corta duración y se eliminan después de ser funsionadas con la rama principal.

¿Por qué construimos esto?

Para obtener más información sobre el CD mínimo y respuestas a otras preguntas comunes, por favor lea las preguntas más frecuentes.

¿Quieres contribuir?

Lee nuestra pauta de contribución.

Firmantes

Los firmantes avalan la versión original en inglés y la lista actual de nombres solo se publica con esa versión.

Traducción

Esta traducción es un esfuerzo de la comunidad para ayudar a transmitir esta información más allá de las barreras lingüísticas. Los firmantes mismos no pueden confirmar la exactitud de la traducción.

Traducido de la versión del documento: dfc3ab8, 2021-11-04

3 - Francais

Le minimum viable de la Livraison Continue

“La livraison continue améliore à la fois les performances de livraison et la qualité, et participe également à améliorer la culture et à réduire l’épuisement et la difficulté des déploiements.”

– Accelerate

Nous, les signataires, estimons qu’une définition minimale de la Livraison Continue (Continuous Delivery, CD) est requise afin d’améliorer les flux de livraisons. Bien que chaque contexte soit unique, il y a des pratiques universelles. En les définissant, nous pouvons :

• Présenter les choses aux nouveaux arrivants de manière cohérente
• Discuter des pratiques d’ingénierie qui composent le CD (Continuous Delivery)
• S’entraider pour améliorer nos capacités actuelles

Ce n’est qu’en mettant en œuvre des pratiques fondamentales qu’il est possible de commencer à voir les avantages de la livraison continue.

Les pratiques ci-dessous sont le minimum, un point de départ. L’amélioration continue de la vitesse, de la qualité et de la sécurité du pipeline de livraison en sont le résultat attendu.

Livraison Continue

La Livraison Continue est la discipline d’ingénierie qui consiste à délivrer tous les changements de manière standard, en toute sécurité. Il couvre un large éventail d’activités en fonction de ce qui est livré. Cependant, il existe des comportements et des compétences qui doivent être mises en oeuvres dans tous les contextes pour être qualifiés de « livraison continue »

Les activités minimales requises pour la Livraison Continue sont :

• L’intégration continue
• Le pipeline de déploiement est le seul chemin qui permet de déployer en production.
• Le pipeline décide de la diffusion des modifications, son verdict est définitif
• Les artefacts créés par le pipeline répondent toujours à la définition de Déployable de l’organisation
• L’artefact ne change jamais. Il n’y a aucun changement humain après le commit.
• Tous les travaux sur les fonctionnalités s’arrêtent lorsque le pipeline est rouge
• L’environnement de test est proche de l’environnement de production
• On peut revenir en arrière (rollback) à la demande
• La configuration de l’application est déployée avec l’artefact

Intégration Continue

L’Intégration Continue consiste à intégrer, très fréquemment, un travail donné au tronc principal du dépôt de code, et à vérifier que ce travail est, à notre connaissance, propre à être livré.

Les activités minimales requises pour CI sont :

• Le développement basé sur un tronc commun
• Le travail est intégré au tronc commun au moins une fois par jour
• Le travail est testé automatiquement avec d’être fusionné au tronc commun
• Le travail est testé avec celui des autres automatiquement lors de la fusion
• Tous les travaux sur les fonctionnalités s’arrêtent lorsque le build est rouge
• Le nouveau travail ne casse pas le travail existant

Le développement basé sur un tronc commun (Trunk-based Development, TBD)

Le développement basé sur un tronc commun est le modèle de branche requis pour répondre à la définition d’Intégration Continue. Il évite la perte de travail, le risque de corruption qui provient des résolutions de conflits lors des fusions, et réduit également le gaspillage d’énergie induit par la taille des lots/

Les activités minimales requises pour le TBD sont :

• Tous les changements sont intégrés dans le tronc commun
• Si des branches partant du tronc commun sont utilisées :
  • Elles sont issues du tronc commun
  • Elles sont réintègrées au tronc commun
  • Elles sont de courte durée et supprimées après la fusion

Pourquoi avons-nous construit ce manifeste ?

Pour plus d’informations sur la Livraison Continue Minimale et des réponses à d’autres questions courantes, veuillez lire la FAQ.

Vous souhaitez contribuer ou devenir signataire ?

Les signataires ont signé le document original en anglais, et la liste des noms sera tenue à jour uniquement sur celui-ci.

Traduction

Cette traduction est produite par la communauté pour obtenir ces informations au-delà des barrières linguistiques. Les signataires eux-mêmes ne peuvent confirmer l’exactitude de cette traduction.

Traduit de la version: 35071d4, 2023-07-18

3.1 - Au-delà des minimums

Au-delà des minimums

La Livraison Continue Minimale n’est pas la première étape d’un modèle de maturité. Cependant, cela reste le strict minimum sur lequel de nombreuses autres pratiques devraient être construites en fonction de votre contexte. Afin de vous aider à dépasser cette Livraison Continue Minimale, nous tenons à jour une liste de ressources axées sur la livraison continue, que nous que nous avons trouvées très utiles dans nos propres expériences.

Ces ressources contiennent les bases, mais aussi les connaissances nécessaires pour devenir une organisation de Livraison Continue « d’élite ». Elles sont dédiées à la résolution du problème « pourquoi ne pouvons-nous pas passer en production aujourd’hui ? »

Lire la liste.

4 - Italiano

Implementazione minima della Continuous Delivery

“La Continuous Delivery migliora sia la velocità di rilascio che la qualità del software ed aiuta a migliorare la cultura, riduce i burnout e gli sforzi tipici legati al rilascio del software in produzione”.

– Accelerate (Unofficial translation)

Noi, i firmatari, riteniamo che la definizione di un’implementazione minima della Continuous Delivery (CD) sia necessaria per migliorare il flusso di rilascio del software. Sebbene i contesti in cui lavoriamo possano essere diversi, esistono pratiche universali. Definendo tali pratiche possiamo:

• Introdurre alla Continuous Delivery nuovi praticanti in modo coerente
• Discutere le pratiche ingegneristiche che costituiscono CD
• Aiutarci a vicenda a migliorare le nostre conoscenze e capacità attuali

Soltanto partendo da questo set minimo di pratiche essenziali potremmo iniziare a vedere i vantaggi della Continuous Delivery.

Le pratiche sotto elencate costituiscono un’implementazione minima, un punto di partenza. Il risultato atteso è il miglioramento continuo della velocità, della qualità e della sicurezza della pipeline di rilascio.

Continuous Delivery

La CD è la disciplina ingegneristica che consente di rilasciare nuove funzionalità e modifiche software in modo standard e sicuro. La CD copre un ampio spettro di attività a seconda di cosa deve essere rilasciato. Tuttavia, ci sono comportamenti ed abilità che devono essere rispettati in qualsivoglia contesto, perché si possa parlare di “Continuous Delivery”.

Il set minimo di attività richieste per la CD sono:

• Continuous integration (Integrazione Continua)
• La application pipeline è l’unico percorso per il rilascio in produzione
• La pipeline decide la rilasciabilità delle modifiche software, e il suo verdetto è definitivo
• Gli artefatti creati dalla pipeline soddisfano sempre la definizione di rilasciabilità definition of deployable della specifica organizzazione
• Artefatti immutabili (Immutable artifact): nessuna modifica manuale dopo i commit
• Tutto il lavoro si ferma se la pipeline fallisce
• Utilizzare ambienti di test il più possibile simili all’ambiente di produzione
• Rollback su richiesta
• La configurazione dell’applicazione viene distribuita assieme agli artefatti

Continuous Integration (Integrazione continua)

La CI è l’attività che ci consente di integrare continuamente il lavoro di ciascun membro del team nel trunk del repository e verificare che questo sia sempre, al meglio delle nostre conoscenze, funzionante e rilasciabile.

Le attività minime richieste dalla CI sono:

• Trunk-based development
• Il lavoro viene integrato nel trunk almeno una volta al giorno
• Una suite di test automatici verifica il lavoro prima che venga integrato nel trunk
• Una suite di test automatici verifica il lavoro dopo essere stato integrato nel trunk
• Tutto il lavoro si ferma se la pipeline fallisce
• Il nuovo lavoro non deve causare malfunzionamenti alle funzionalità già rilasciate

Trunk-based Development

Il Trunk-based Development è il modello di branching necessario a soddisfare la definizione della CI. La CI evita la perdita delle modifiche, il rischio di corruzione che deriva dall’integrazione e dalla risoluzione dei conflitti, e riduce lo spreco dovuto ad attività che potrebbero aumentare la dimensione degli insiemi di modifiche.

• Le attività minime richieste dal TBD sono:
  • Tutte le modifiche devono essere integrate nel trunk
  • Se si utilizzano i branch:
    • Devono nascere dal trunk
    • Devono essere reintegrati nel trunk
    • Devono essere di breve durata e rimossi dopo l’integrazione

Oltre il minimo

La CD minima non è il primo passo in un modello di maturità, tuttavia è il minimo indispensabile su cui dovrebbero essere costruite molte altre pratiche, come richiesto dal proprio contesto. Per facilitare il vostro percorso oltre la CD minima, manteniamo di seguito una lista di risorse relative alla Continuous Delivery che abbiamo trovato molto utili nel nostro percorso.

Queste risorse contengono sia conoscenze di base, sia conoscenze necessarie a farvi diventare un’organizzazione CD “d’élite”. Sono risposte specifiche alla domanda “Cosa ci impedisce di andare in produzione oggi?”

Vedi la lista.

Perche abbiamo costruito questa lista?

Per maggiori dettagli sulla CD minima e risposte su altre domande comuni, vi rimandiamo alle FAQs.

Per contribuire o diventare firmatari

Vedere linee guida per contribuire.

Firmatari

I firmatari hanno firmato la versione originale in inglese e la lista corrente dei nomi è pubblicata solo in quella versione

Traduzione

Questa traduzione è uno sforzo della comunità per facilitare la diffusione dei concetti legati alla CD oltre la barriera linguistica. I firmatari non possono confermare la correttezza della traduzione.

Tradotto dalla versione: 4de610d, 2021-10-19

4.1 - Domande Frequenti (FAQ)

Motivazioni

Nell’ottobre 2021, durante il summit DevOps Enterprise, molti di noi si sono incontrati per discutere il problema del costante fraintendimento della Continuous Delivery. Abbiamo quindi deciso di condurre un esperimento per migliorarne la comprensione.

Nel libro “Accelerate” del 2017, gli autori osservavano che:

“La Continuous Delivery migliora sia la velocità di rilascio che la qualità del software ed aiuta a migliorare la cultura, riduce i burnout e gli sforzi tipici legati al rilascio del software in produzione”.

Tale osservazione è basata sulla loro esperienza e sui dati raccolti negli anni tramite i questionari “State of DevOps” (“Stato della DevOps”). Noi stessi abbiamo constatato gli stessi risultati, ma soltanto utilizzando in modo appropriato un set di pratiche fondamentali. Quando queste pratiche non vengono utilizzate, vengono fraintese o un’organizzazione tenta di prendere scorciatoie, i risultati non arrivano e allora si tende a dire che la CD è una moda passeggera o che non è adatta al proprio, speciale, contesto. Nessuna delle due affermazioni corrisponde a verità.

Stabilendo una linea di partenza, speriamo di fornire una chiara tabella di marcia di azioni fondamentali che devono essere messe in pratica. Se ci chiedessimo “perché non possiamo farlo anche noi?” e quindi procedessimo a risolvere quei problemi, riusciremmo ad ottenere gli stessi benefici di cui dicono di godere le altre organizzazioni.

Perché firmare?

Se pratichi la CD e sei d’accordo con con questi obiettivi, sentiti libero di inviare una Pull Request per aggiungere la tua firma.

Cosa fare se cambio idea?

Non vogliamo tenere nessuno in ostaggio. Il nostro obiettivo è elevare il confronto attraverso un linguaggio comune. Basta quindi aprire una issue o inviare una nuova PR. La firma sarà rimossa prontamente.

Come viene aggiornata la lista delle pratiche?

I manutentori della lista operano attraverso il consenso. Per essere inserita nella lista, ciascuna pratica deve essere essenziale a prescindere dal contesto. Se una pratica non è nella lista significa che, o non soddisfa lo standard minimo assoluto in ogni contesto, o è in conflitto con una delle pratiche elencate. Il miglior modo per suggerire una modifica o un’aggiunta alla lista è creare una “issue” su GitHub.

È solo questo ciò di cui abbiamo bisogno per implementare la CD?

Oh, no, questo è il minimo indispensabile.

Come possiamo utilizzare questi contenuti per migliorare?

La CD richiede la CI (Continuous Integration) e la CI richiede il Trunk-based Development. Comincia dal fondo e procedi verso l’alto. Chiediti: “perché non riusciamo ancora a realizzare questa o quell’altra cosa?”. Risolvere quel problema è il motore del miglioramento dell’organizzazione. Non abbiamo ancora constatato un singolo caso in cui la CD non potesse essere applicata. In alcuni contesti, potrebbe solo volerci più tempo per risolvere certi problemi. Ne vale comunque la pena. La CD migliora tutto.

Perché la pipeline dovrebbe dettare legge per il rilascio?

“Se la pipeline riporta che tutto è funzionante, ciò è quanto basta - ci spinge a concentrarci su cosa significa “rilasciabile.” - Dave Farley

Cos’è la configurazione dell’applicazione (Application Configuration)?

Il termine “Configurazione” è abusato e non ha una definizione standard in tutto il nostro settore. Noi sposiamo la definizione The Twelve-Factor Appconfig in cui “configurazione” dipende dell’ambiente di installazione (varia in base al rilascio) e “configurazione dell’applicazione” è interna all’applicazione e NON varia in base all’ambiente di installazione.

Cosa significa artefatti immutabili?

Fondamentale per CD è che che gli artefatti distribuiti tramite la pipeline vengano validati. Lo stesso artefatto viene creato una volta e distribuito in tutti gli ambienti. Una cattiva pratica comune è costruire un artefatto per ogni ambiente. Questo è il motivo per cui il trunk-based development è così importante.

Che cosa intendiamo per “rilasciabile” (deployable)?

Ogni organizzazione dovrebbe adottare criteri non negoziabili per i rilasci software. Questi potrebbero includere i controlli di sicurezza, conformità, stabilità, reattività, ecc. La pipeline dovrebbe avere l’ultima parola per tutto ciò. Raccomandiamo il video di Dave Farley Esempio reale di una pipeline di rilascio nel settore Fintech

5 - Português

Mínimo viável para a Entrega Contínua

Nós, os abaixo-assinados, acreditamos que é necessária uma definição mínima de entrega contínua (Continuous Delivery, CD) para a melhoria do fluxo de entrega e cumprimento dos resultados supracitados. Embora os nossos contextos possam ser diferentes, existem práticas universais consideradas comuns. Ao defini-las, é possível:

• Introduzi-las aos novos praticantes, de forma consistente
• Discutir as práticas de engenharia que abrangem a entrega contínua
• Ajudar-nos mutuamente, melhorando as capacidades atuais

Só através da adoção de práticas elementares é que se torna possível testemunhar os benefícios da entrega contínua.

As práticas descritas em seguida são o mínimo, ou seja, um ponto de partida. O resultado esperado é a melhoria da rapidez, qualidade e segurança da pipeline de entrega.

Entrega Contínua

A entrega contínua (CD) é a disciplina de engenharia que consiste na entrega de todas as alterações, de forma padronizada, com segurança. Ela cobre um extenso espetro de atividades, dependendo do que está a ser entregue. Porém, há comportamentos e habilidades que devem ser considerados, em todos os contextos, para que o processo possa ser classificado como “entrega contínua”.

As atividades mínimas exigidas para o CD são:

• Uso de Integração contínua
• A pipeline aplicational é a única forma possível de fazer deploy para qualquer ambiente
• A pipeline decide a possibilidade dessas mudanças serem replicadas para o ambiente produtivo. Esse veredicto é definitivo
• Os artefactos criados pela pipeline respeitam sempre a definição de deployable da organização
• Artefacto imutável (não existem mudanças manuais após o commit)
• Todo o desenvolvimento de funcionalidades é suspenso quando a pipeline se encontra em falha (em vermelho)
• Ambientes de teste semelhantes ao ambiente produtivo
• Rollback conforme necessário
• A configuração da aplicação é deployed com o artefacto

Integração Contínua

A integração contínua (Continuous Integration, CI) é a atividade que consiste em frequentemente integrar o trabalho desenvolvido no trunk do sistema de controlo de versões e verificar que esse trabalho, dentro do que se conhece, é passível de ser released.

As atividades mínimas necessárias ao CI são:

• Trunk-based development
• O trabalho integra em trunk, no mínimo, diariamente
• O trabalho tem testes automatizados antes do merge em trunk
• O trabalho é testado automaticamente com outras mudanças no merge
• Todo o trabalho em funcionalidades é suspenso quando a build falha
• Novo trabalho não quebra o trabalho já entregue

Trunk-Based Development

O Trunk-based development (versão inglesa) (TBD) é um padrão de branching essencial para cumprimento dos requisitos de CI. Impede a perda de trabalho, o risco de mudanças corrompidas devido à resolução de conflitos do merge e também reduz o desperdício de movimento que aumenta o tamanho do batch de mudanças.

Os atividades mínimas essenciais para o TBD são:

• Todas as mudanças integram em trunk
• No caso de serem usados branches:
  • Eles têm sempre origem em trunk
  • Eles re-integram sempre em trunk
  • Eles são de curta-duração e são removidos depois do merge

Por que construímos este manifesto?

Para obter informações acerca do Mínimo CD e respostas a outras questões comuns, por favor lê as FAQ (versão inglesa).

Começando a jornada

Dúvidas sobre como começar? Confira algumas recomendações (versão inglesa).

Contribuindo

Você quer enviar uma tradução, boas práticas, sugestões ou um relato de experiência?

Lê as nossas diretrizes de contribuição (versão inglesa).

Signatários

Os signatários assinaram a versão original em inglês e a lista atual de nomes é publicada apenas nessa versão.

Tradução

Esta tradução é um esforço de toda a comunidade, que tem como objetivo a disseminação destes conceitos, para lá das barreiras linguísticas. Os signatários abstêm-se de afirmar a exatidão da tradução.

Traduzido da versão: 52efc0bd, 2023-02-06

6 - Português Brasileiro

Mínimo viável para a Entrega Contínua

Nós, os abaixo-assinados, acreditamos que é necessária uma definição mínima de entrega contínua (Continuous Delivery, CD) para a melhoria do fluxo de entrega e cumprimento dos resultados supracitados. Embora os nossos contextos possam ser diferentes, existem práticas universais consideradas comuns. Ao defini-las, é possível:

• Introduzi-las aos novos praticantes, de forma consistente
• Discutir as práticas de engenharia que abrangem a entrega contínua
• Ajudar-nos mutuamente, melhorando as capacidades atuais

Só através da adoção de práticas elementares é que se torna possível testemunhar os benefícios da entrega contínua.

As práticas descritas em seguida são o mínimo, ou seja, um ponto de partida. O resultado esperado é a melhoria contínua da rapidez, qualidade e segurança da pipeline de entrega.

Entrega Contínua

A entrega contínua (CD) é a disciplina de engenharia que consiste na entrega de todas as alterações, de forma padronizada e segura. Ela cobre um amplo espectro de atividades, dependendo do que está sendo entregue. Porém, há comportamentos e habilidades que devem ser considerados, em todos os contextos, para que o processo possa ser classificado como “entrega contínua”.

As atividades mínimas exigidas para o CD são:

• Uso de Integração contínua
• O delivery pipeline é a única forma possível de fazer deploy para qualquer ambiente
• O pipeline decide se as mudanças atendem ou não os requisitos para entrada em produção. Esse veredicto é definitivo
• Os artefatos criados pelo pipeline respeitam sempre a definição de deployable da organização
• Artefato imutável (não existem mudanças manuais após o commit)
• Todo o desenvolvimento de funcionalidades é suspenso quando o pipeline falha
• Ambiente de testes semelhante ao ambiente produtivo
• Rollback sob demanda
• A configuração da aplicação é implantada junto com o artefato

Integração Contínua

A integração contínua (Continuous Integration, CI) é a atividade que consiste em frequentemente integrar o trabalho desenvolvido no trunk do sistema de controle de versões e verificar que esse trabalho, tanto quanto podemos afirmar, é passível de ser released.

As atividades mínimas necessárias ao CI são:

• Trunk-based development
• O trabalho integra em trunk, no mínimo, diariamente
• O trabalho tem testes automatizados antes do merge em trunk
• O trabalho é testado automaticamente com outras mudanças no merge
• Todo o trabalho em funcionalidades é suspenso quando a build falha
• Trabalho novo não quebra trabalho entregue

Trunk-Based Development

O Trunk-based development (versão inglesa) (TBD) é um padrão de branching mandatório para cumprimento dos requisitos de CI. Evita a perda de trabalho, o risco de mudanças corrompidas devido à resolução de conflitos do merge e também reduz o desperdício de movimento que aumenta o tamanho do batch de mudanças.

As atividades mínimas necessárias para o TBD são:

• Todas as mudanças integram em trunk
• No caso de serem usados branches:
  • Eles têm sempre origem em trunk
  • Eles re-integram sempre em trunk
  • Eles são de curta-duração e são removidos depois do merge

Por que construímos este manifesto?

Para obter informações acerca do Mínimo CD e respostas a outras questões comuns, por favor leia o FAQ (versão inglesa).

Começando a jornada

Dúvidas sobre como começar? Confira algumas recomendações (versão inglesa).

Contribuindo

Você quer enviar uma tradução, boas práticas, sugestões ou um relato de experiência?

Leia as nossas diretrizes de contribuição (versão em inglês).

Signatários

Os signatários assinaram a versão original em inglês e a lista atual de nomes é publicada apenas nessa versão.

Tradução

Esta tradução é um esforço de toda a comunidade, que tem como objetivo a disseminação destes conceitos, superando as barreiras linguísticas. Os signatários abstêm-se de afirmar a exatidão da tradução.

Traduzido da versão: 1ba1d25, 2023-04-18

7 - Sinhala

අඛණ්ඩ බෙදාහැරීමට හැකි මෘදුකාංග නිපදවීමට අවමයෙන් කලයුතු සහ කලහැකිදේ

අපි, පහළින් අත්සන් කර ඇත්තන්, අඛණ්ඩව බෙදාහැරීමට හැකි මෘදුකාංග නිපදවීමේ ප්‍රවාහය (CD) වැඩිදියුණු කිරීමට සහ ඉහත ප්‍රතිඵල සාක්ෂාත් කර ගැනීමට අවම අර්ථ දැක්වීමක් අවශ්‍ය බව අපි විශ්වාස කරමු.

• නව නියුක්තිකයින් මේ ක්‍රියාවලිය පැහැදිලිලෙස හඳුන්වා දීම
• අඛණ්ඩව බෙදාහැරීමට හැකි මෘදුකාංග නිපදවීමේ (CD) ඉංජිනේරු ක්‍රියාමාර්ගවල සංයුතිය සාකච්ඡාවට බාජනය කිරීම
• එය කිරීමට එකිනෙකාට උදව් කිරීම

මේ අඛණ්ඩව බෙදාහැරීමට හැකි මෘදුකාංග නිපදවීමේ ක්‍රියාවලියේ ප්‍රතිලාභ අපට දැකීමට පුළුවන්වන්නේ මෙය ක්‍රියාත්මක කිරීමෙන් පමණි.

පහත සඳහන් උපදෙස් අවමයෙන් කලයුතුදේ වේ. මෘදුකාංග නිපදවීමේ ක්‍රියාවලිය නොකඩවා සිදුවෙන්නක් වෙන අතර; එහි කාර්යක්ෂමතාවය, ගුණාත්මකභාවය සහ ආරක්ෂාව සහතික කලහැකි මාධ්‍යයක් (delivery pipeline) සාදාගැනීම මෙහි අපේක්ෂිත ප්රතිඵලය වේ.

අඛණ්ඩ බෙදාහැරීමට හැකි මෘදුකාංග නිපදවීම

CD යනු මෘදුකාංග වලට කෙරෙන සියලු වෙනස්කම් එකම සම්මත ආකාරයෙන් ආරක්ෂිතව ලබා දීමේ ඉංජිනේරු විනයයි. ඔබ එය කරන්නේ කෙසේද යන්න රඳා පවතින්නේ ඔබ කරන වැඩේ මතය. කෙසේ වෙතත්, “අඛණ්ඩ බෙදාහැරීම” ලෙස යෝග්‍යතාව ලබන්න කළ යුතු දේවල් තිබේ

CD සඳහා අවශ්‍ය අවම ක්‍රියාකාරකම් වන්නේ:

• Continuous Integrationභාවිතා කලයුතුවේ

• එම මෘදුකාංග යෙදුම් මාර්ගය pipeline මෘදුකාංග බෙදාහැරීමේ එකම මාර්ගය වේ

• එම යෙදුම් මාර්ගය (pipeline) වෙනස්කම්වල මුදා හැරීම තීරණය කරයි, එහි තීන්දුව නිශ්චිත තීන්දුවවේ

• එම මාර්ගයෙන් නිර්මාණය කරන ලද වස්තුන් සෑම විටම ආයතනයේ බෙදාහැරිය හැකි අර්ථ දැක්වීම සපුරාලයි

• විචල්‍ය නොවන වස්තුන් (සැකසීමෙන් පසු කිසි පුද්ගලයෙකුට මේ වස්තුන් වෙනස් කල නොහැක)

• මෘදුකාංග යෙදුම් මාර්ගය (pipeline) රතු වූ විට සියලුම සියලු වැඩ නතර වේ

• Production-වලට සමාන පරීක්ෂණ පරිසර

• සැණකින් ප්‍රකූර්ති තත්වයට පත්කල හැකි පරීක්ෂණ පරිසර

• යෙදුම් වින්‍යාසයවස්තුන් සමඟ එකට බෙදාහැරේ

Continuous Integration

CI යනු කරපු වැඩ නිතර නිතර Trunk Branch එකට ඒකාබද්ධ කිරීමේ ක්‍රියාකාරකම වන අතර, එය අපගේ උපරිම දැනුමට අනුව අවශ්‍ය ඕනෑම විටකදී Production එකට බෙදාහැරිය හැකි බව තහවුරු කරයි.

CI සඳහා අවශ්‍ය අවම ක්‍රියාකාරකම් වන්නේ:

• Trunk-based development
• කරන වැඩ අවම වශයෙන් දිනපතා Trunk එකට ඒකාබද්ධ වියයුතුවේ
• වැඩ ඒකාබද්ධ කිරීමට පෙර ස්වයංක්‍රීය පරීක්ෂාවට බාවිතාකල යුතුවේ
• ඒකාබද්ධ වීමේදී ස්වයංක්‍රීයව අනිත් කරපු වැඩ සමඟ පරීක්ෂා කළයුතු වේ
• build එක රතු වූ විට සියලුම සියලු වැඩ නතර වේ
• අලුතින් කරපු වැඩ නිසා නිමාකල වැඩ අඩපණවීම් කඩාවැටීම් විය නොහැක

Trunk Based Development

Trunk-based සංවර්ධනය යනු නිර්වචනය වන්නේ මූලාශ්‍ර පාලනයට අවශ්‍ය එක අත්තක් විතරක් බාවිතාකරන රටාවයි, වෙනත් විදියකට CI ක්‍රියාවලිය කල නොහැක. මෙම විදිය code ඒකාබද්ධ වීමේදී සිදුවෙන දුෂිතවීම් වලක්වයි

TBD සඳහා අවශ්‍ය අවම ක්‍රියාකාරකම් වන්නේ:

• සියලුම වෙනස්කම් කඳට අනුකලනය වේ
• කඳෙන් අතු භාවිතා කරන්නේ නම්:
• ඔවුන් කඳෙන් ආරම්භ වේ
• ඔවුන් කඳට නැවත ඒකාබද්ධ වේ
• ඒවා කෙටිකාලීන වන අතර ඒකාබද්ධ වීමෙන් පසුව ඉවත් කරනු ලැබේ

ඇයි අපි මේක හැදුවේ?

අවම CD පසුබිම සහ අනෙකුත් පොදු ප්‍රශ්නවලට පිළිතුරු සඳහා, කරුණාකර නිති අසන ප්‍රශ්න කියවන්න.

ගමන ආරම්භ කිරීම

ආරම්භ කළ යුත්තේ කොතැනින්ද යන්න පිළිබඳ ප්‍රශ්න? සමහර නිර්දේශ. බලන්න.

දායක වීම

ඔබට පරිවර්තනයක්, හොඳ භාවිතයන්, යෝජනා, හෝ අත්දැකීම් වාර්තාවක් ඉදිරිපත් කිරීමට අවශ්‍යද?

අපගේ දායකත්ව මාර්ගෝපදේශ කියවන්න.

දායකයින්

Signatories

8 - Suomi

Vähäisin toimiva jatkuva toimittaminen

“Continuous delivery improves both delivery performance and quality, and also helps improve culture and reduce burnout and deployment pain.”

– Accelerate

Me, allekirjoittaneet, uskomme, että jatkuvalle toimittamiselle (engl. continuous delivery, CD) tarvitaan määritelmä, jotta toimitusvirtaa voidaan parantaa. Riippumatta erilaisista olosuhteistamme, on olemassa yleispäteviä käytäntöjä. Määrittelemällä nämä käytännöt voimme:

• Perehdyttää uudet harjoittajat yhdenmukaisella tavalla
• Keskustella ohjelmistotuotannon käytännöistä, joista CD muodostuu
• Auttaa toisiamme kehittämään nykyisiä kyvykkyyksiä

Ainoastaan toteuttamalla ydinkäytännöt alamme nähdä jatkuvan toimittamisen hyödyt.

Alla olevat käytännöt ovat minimi, lähtötila. Käytäntöjen seuraamisesta on odotettavissa jatkuvasti kehittyvää nopeutta, laatua ja toimitusputken turvallisuutta.

Jatkuva toimittaminen

Jatkuva toimittaminen (CD) on ohjelmistotuotannon toimintamalli, jolla kaikki muutokset toimitetaan samalla turvallisella tavalla. Siihen liittyy laaja joukko käytäntöjä, joiden toteuttaminen riippuu siitä, mitä ollaan toimittamassa. Tästä huolimatta on toimintaa ja kyvykkyyksiä, jotka täytyy toteuttaa kaikissa toimintaympäristöissä, jotta toimintaa voidaan kutsua “jatkuvaksi toimittamiseksi”.

Jatkuvan toimittamisen minimivaatimukset ovat:

• Jatkuva integraatio
• Sovelluksen toimitusputki on ainoa tie tuotantoonvientiin.
• Toimitusputki määrää muutosten julkaisukelpoisuuden, sen lausunto on ehdoton
• Organisaation tuotantoonvientikelpoisen määritelmä täyttyy aina
• Artifakti on muuttumaton. Ei ihmisen tekemiä muutoksia versionhallintaan tallentamisen jälkeen.
• Kaikki uuskehitys loppuu, kun toimitusputki on punaisella
• Tuotannonkaltainen testiympäristö
• Tuotantoonviennin peruutus tarvittaessa
• Sovelluksen konfiguraatio viedään tuotantoon artifaktin kanssa

Jatkuva integraatio

Jatkuva integraatio (CI) on toimintatapa, jossa työ integroidaan päähaaraan erittäin usein ja varmistetaan, että työ on - parhaan tietomme mukaan - julkaisukelpoista.

Jatkuvan integraation minimivaatimukset ovat:

• Päähaarassa kehittäminen (Trunk-based development)
• Työ integroidaan päähaaraan vähintään päivittäin
• Työ testataan automaattisesti ennen päähaaraan yhdistämistä
• Työ testataan muun työn kanssa automaattisesti haaroja yhdistettäessä
• Kaikki uuskehitys loppuu, kun integroimisputki on punaisella
• Uusi työ ei riko toimitettua työtä

Päähaarassa kehittäminen (Trunk-based Development)

Päähaarassa kehittäminen eli Trunk-based development on versionhallinnan haarauttamistapa, joka vaaditaan jatkuvan integraation määritelmään. Se estää työn katoamisen, työn korruptoitumisen haarojen yhdistämiseen liittyvissä konflikteissa ja vähentää liike-hukkaa, joka johtaa suuriin eräkokoihin.

Päähaarassa kehittämisen minimivaatimukset ovat:

• Kaikki muutokset integroidaan päähaaraan
• Jos päähaarasta otetaan lisää haaroja, ne:
  • Haarautuvat päähaarasta
  • Integroituvat uudelleen päähaaraan
  • Ovat lyhytikäisiä ja poistetaan päähaaraan yhdistämisen jälkeen

Vähimmästä eteenpäin

Minimi-CD ei ole ensimmäinen askel kypsyysmallissa. Siitä huolimatta se on vähäisin taso, jonka päälle muita tarkoituksenmukaisia toimintoja on ympäristöstäsi riippuen syytä rakentaa. Auttaaksesi tielläsi lähtötilanteesta eteenpäin, ylläpidämme listaa lähteistä, jotka keskittyvät jatkuvan toimittamiseen ja joista on ollut meille apua omilla matkoillamme.

Näistä lähteistä löytyy sekä perusasiat että tiedot, joilla voi tulla “eliitti”-CD-organisaatioksi. Ne keskittyvät ratkaisemaan ongelman: “Miksei me voida mennä tuotantoon tänään?”

Lue lista.

Miksi teimme tämän?

Lisää taustatietoa Minimi-CD:stä ja vastauksia yleisimpiin kysymyksiin löytyy usein kysytyistä kysymyksistä.

Haluatko osallistua tai allekirjoittaa?

Lue osallistumisohje.

Allekirjoittajat

Allekirjoittajat ovat allekirjoittaneet englanninkielisen alkuperäisdokumentin ja ajantasainen nimilista julkaistaan ainoastaan sen yhteydessä.

Käännös

Tämä on yhteisön tuottama käännös, jotta tämä tieto kulkisi yli kielimuurien. Allekirjoittaneet eivät itse voi vahvistaa tämän käännöksen oikeellisuutta.

Käännetty dokumenttiversiosta: ab846ca, 2021-10-16

9 - Texan

We, the undersigned, reckon that parin’ down continuous delivery (CD) to its core is required if we wanna improve the flow of delivery and achieve the outcomes above. While our contexts may vary, there are universal practices common in all. By defining ’em, we can:

• Introduce new practitioners in a consistent way
• Discuss engineering practices that make up CD
• Help each other get better at doin’ it

Only by implementin’ core practices do we begin to see the benefits of continuous delivery.

The practices below are the bare minimum, a startin’ point. Continuous improvement of the speed, quality, and safety of the delivery pipeline is the expected outcome. If all y’all do is automate some things then bless your heart, ain’t nothing gettin’ better.

Continuous Delivery

CD is the engineering discipline of deliverin’ all changes in a standard way safely. How you do it depends on what’s bein’ delivered. However, there are things you gotta do in every context to qualify as “Continuous Delivery”

The minimum activities required for CD are:

• Use Continuous Integration
• The application pipeline is the only way to deploy to any environment
• The pipeline decides the releasability of changes. Whatever it says, goes
• Artifacts created by the pipeline always meet the organization’s definition of deployable
• Immutable artifact (no human changes after commit)
• All feature work stops when the pipeline is red
• Production-like test environment
• Rollback on-demand
• Application configuration deploys with artifact

Continuous Integration

CI is the activity of mighty frequently integratin’ work to the trunk of version control and verifyin’ that the work is, best we can tell, releasable.

The bare minimums for CI are:

• Trunk-based development
• Work integrates into the trunk at least daily
• Y’all automated the testin’ before mergin'
• Work is tested with other work automagically on merge
• All feature work stops when the build halts and catches fire
• New work does not mess up delivered work

Trunk-based Development

Trunk-based development is the branchin’ pattern we need to meet the definition of CI. It prevents lost work, the risk of corruption that comes from conflictin’ changes, and reduces back-and-forth commiseratin’ that makes changes bigger.

The minimum activities required for TBD are:

• Everythin’ integrates into the trunk
• If branches from the trunk are used:
  • They start at the trunk
  • They end at the trunk
  • Like mayflies, they should die within a day

Why’d we build this?

We wrote that down along with some other stuff to help y’all out.

Headin’ Down the Trail

Wanna know where to start? Check out some ideas that’ve worked for us.

Contributin'

Do you want to submit a translation, good practices, suggestions, or talk about what’s worked for you?

Read our contribution guidelines.

Contributors

Signatories