Was ist CI/CD?

CI/CD (Continuous Integration/Continuous Delivery oder Deployment, Kontinuierliche Integration, Übermittlung und Bereitstellung) ist eine Praxis der Softwareentwicklung, die auf Automatisierung basiert. Häufige, zuverlässige Updates beschleunigen die Veröffentlichungszyklen dank kontinuierlicher Codebereitstellung.

CI/CD im Überblick

CI/CD ist ein Oberbegriff, der tatsächlich mehrere DevOps-Phasen abdeckt. CI (Continuous Integration, kontinuierliche Integration) bezeichnet die Praxis, Codeänderungen mehrmals täglich in ein Repository zu integrieren. CD hat zwei Bedeutungen: Continuous Delivery (Kontinuierliche Übermittlung) automatisiert die Integration des Codes, während Continuous Deployment (Kontinuierliche Bereitstellung) die Bereitstellung der endgültigen Builds für die Endbenutzer bezeichnet. Die häufigen Tests im Rahmen von CI/CD reduzieren die Anzahl der Fehler und Defekte und machen CI/CD zu einem wichtigen Bestandteil jedes DevOps-Workflows.

Kontinuierliche Integration (CI)

CI ist eine Best Practice für DevOps und zugleich die Phase im DevOps-Lebenszyklus, in der Entwickler Code in das gemeinsame Code-Repository einchecken, oft mehrmals am Tag. Im Idealfall prüft dabei ein automatisches Build-Tool den eingecheckten Code oder die Verzweigung, um sicherzustellen, dass keine Fehler enthalten sind und der Code in die Produktion übernommen werden kann. Der Hauptvorteil besteht darin, dass Probleme in der Regel frühzeitig abgefangen werden, noch bevor sie sich zu größeren Problemen auswachsen.

CI bedeutet in der Praxis, Änderungen in kleinem Umfang in kürzerer Zeit anstelle umfangreicher Aktualisierungen zu integrieren, die mehr Zeit benötigen, aber weniger häufig vorkommen. Die Automatisierung der Arbeitsabläufe für Test, Zusammenführen und Einchecken von Änderungen in ein gemeinsames Repository ermöglicht die Bereitstellung von fehlerfreierem Code in kürzerer Zeit. Sauberer Code dieser Art beschleunigt die Validierung, sorgt für fehlerfreiere Veröffentlichungen und zugleich für eine effizientere Entwicklungspipeline, die leichter zu skalieren ist.

Kontinuierliche Integration (CI)

CI ist eine Best Practice für DevOps und zugleich die Phase im DevOps-Lebenszyklus, in der Entwickler Code in das gemeinsame Code-Repository einchecken, oft mehrmals am Tag. Im Idealfall prüft dabei ein automatisches Build-Tool den eingecheckten Code oder die Verzweigung, um sicherzustellen, dass keine Fehler enthalten sind und der Code in die Produktion übernommen werden kann. Der Hauptvorteil besteht darin, dass Probleme in der Regel frühzeitig abgefangen werden, noch bevor sie sich zu größeren Problemen auswachsen.

CI bedeutet in der Praxis, Änderungen in kleinem Umfang in kürzerer Zeit anstelle umfangreicher Aktualisierungen zu integrieren, die mehr Zeit benötigen, aber weniger häufig vorkommen. Die Automatisierung der Arbeitsabläufe für Test, Zusammenführen und Einchecken von Änderungen in ein gemeinsames Repository ermöglicht die Bereitstellung von fehlerfreierem Code in kürzerer Zeit. Sauberer Code dieser Art beschleunigt die Validierung, sorgt für fehlerfreiere Veröffentlichungen und zugleich für eine effizientere Entwicklungspipeline, die leichter zu skalieren ist.

Kontinuierliche Integration (CI)

CI ist eine Best Practice für DevOps und zugleich die Phase im DevOps-Lebenszyklus, in der Entwickler Code in das gemeinsame Code-Repository einchecken, oft mehrmals am Tag. Im Idealfall prüft dabei ein automatisches Build-Tool den eingecheckten Code oder die Verzweigung, um sicherzustellen, dass keine Fehler enthalten sind und der Code in die Produktion übernommen werden kann. Der Hauptvorteil besteht darin, dass Probleme in der Regel frühzeitig abgefangen werden, noch bevor sie sich zu größeren Problemen auswachsen.

CI bedeutet in der Praxis, Änderungen in kleinem Umfang in kürzerer Zeit anstelle umfangreicher Aktualisierungen zu integrieren, die mehr Zeit benötigen, aber weniger häufig vorkommen. Die Automatisierung der Arbeitsabläufe für Test, Zusammenführen und Einchecken von Änderungen in ein gemeinsames Repository ermöglicht die Bereitstellung von fehlerfreierem Code in kürzerer Zeit. Sauberer Code dieser Art beschleunigt die Validierung, sorgt für fehlerfreiere Veröffentlichungen und zugleich für eine effizientere Entwicklungspipeline, die leichter zu skalieren ist.

Kontinuierliche Integration vs. kontinuierliche Lieferung

Kontinuierliche Übermittlung

Die kontinuierliche Übermittlung folgt auf CI. Sie dient in der Entwicklungspipeline der Kontrolle, bevor dann das Endprodukt veröffentlicht oder für Kunden bereitgestellt wird. Sobald die Codeänderungen validiert wurden, werden sie automatisch in das Repository übernommen.

Ein Ziel der kontinuierlichen Bereitstellung besteht darin, die Änderungssätze so klein zu halten, dass die Aktualisierungen des Hauptbuilds den Status des Endprodukts als „produktionsbereit“ nicht beeinträchtigen, wenn es noch nicht veröffentlichungsfähig ist. Das Endprodukt kann kleinere Fehler enthalten, die aber nicht so gravierend sind, dass sie die Benutzererfahrung beeinträchtigen.

Die Umsetzung der kontinuierlichen Übermittlung bedeutet, dass die Entwickler weniger Zeit für interne Tests aufwenden müssen, weil das gesamte Verfahren sicherstellt, dass nur stabiler Code in die Übermittlungsphase gelangt. Die Fehlererkennung wird vereinfacht und die Zeit bis zur Fehlerbeseitigung dadurch verkürzt.

Vorteile von CI/CD

Schnelle Iteration

Die Nutzung von CI/CD-Verfahren im DevOps-Lebenszyklus beschleunigt die Entwicklung, indem manuelle Arbeiten zur Validierung und Bereitstellung von Änderungen in der Codebasis automatisiert werden.

Sauberer Code

Durch das Einchecken vieler kleiner Änderungen im Tagesverlauf wird die Gefahr, dass Fehler in den Quellcode eingeschleust werden, die Builds beeinträchtigen, erheblich verringert.

Schnellere Fehlerbehebungen

Wenn mit CI/CD kleinere Änderungssätze häufiger zusammengeführt werden, lassen sich Codefehler einfacher erkennen und beheben, bevor sie sich zu einem größeren Problem auswachsen.

Kürzere Feedbackschleifen

Mit CI/CD werden Feedbackschleifen verkürzt, weil kleinere, aufeinander aufbauende Änderungen einfacher zu integrieren, zu testen und bereitzustellen sind – ein zentraler DevOps-Grundsatz.

Bessere Zusammenarbeit

CI/CD strukturiert die Arbeit, indem Prozesse und Zeitpläne für das Übertragen von Code in das Repository und für Build-Veröffentlichungen definiert werden. Aufgrund der klareren Ziele können die Teams flexibler agieren.

Zufriedenere Kunden

Da Builds mit CI/CD immer veröffentlichungsbereit sind, erleben Kunden weniger Serviceunterbrechungen. Zudem kann das Kundenfeedback viel schneller integriert werden.

CI/CD-Lösung von Unity

Profitieren Sie mit den CI/CD-Lösungen von Unity von schneller Codeübernahme und leistungsstarker Quellcodeverwaltung sowie Automatisierungslösungen für Ihr Projekt. Wählen Sie Unity Cloud Build für verteilte Arbeit oder skalieren Sie die Build-Kapazität in Ihrer Umgebung mit Unity Build Server.

Automatisieren der Build-Erstellung

CI/CD Frequently asked questions

Is agile the same as CI/CD?

An agile workflow and CI/CD are related, however, they are not the same! They describe completely different aspects of the software development pipeline. Agile development, refers to the process or methodologies for managing workflows, meeting cadences, and team organization in software development. An agile methodology embraces change while accelerating delivery by listening and responding to customer needs and involving them in each stage of the development process.

CI/CD relies on automation to remove the human elements that create bottlenecks in releasing and improving the software. In both CI and CD testing is automated throughout the pipeline and is done frequently to minimize the costs and time it takes to remediate defects.

How often should you be deploying to production with continuous deployment?

With CI/CD, releases should always be frequent to avoid future problems and assure your software is always in a releasable state - typically deploying multiple times a day. A common assumption with CI/CD teams should be implementing "constant" releases, however, this is not always the case. Your release cycle can vary widely depending on your product, your builds, and other factors you might want to take into consideration such as:

Is it a critical or minor fix?

Are you tracking regression counts from build to build?

Is there a QA team put in place?

Does the code base have unit tests?

Are there any code duplications?

These are just a few examples of aspects to consider when thinking about a release strategy and pipeline, but it differs drastically from team to team. Different products require different approaches.

Is continuous deployment worth it?

There is no one size fits all answer to this question. Before investing in continuous deployment a business must first assess what the biggest risks are of their product and then determine the tradeoffs in how you want to deploy software. The success of your product is dependent on being able to quickly iterate, get feedback from your customers, and continue to make changes. Continuous deployment will be highly impactful and profitable if you are prioritizing shortening feedback loops and building a highly responsive business. However, if your business does not have many customers then the benefits of implementing increments of deployment will add less value and more costs. The staging environment you choose to deploy ultimately depends on your business needs, workflow, and budget.

Does continuous delivery encourage configuration as code?

Continuous delivery does encourage configuration because it continuously makes changes to the original code in the configuration. This ensures that the configuration stays up with code errors that may occur over time.

Was ist CI/CD?

CI/CD im Überblick

Kontinuierliche Integration (CI)

Kontinuierliche Integration (CI)

Kontinuierliche Integration (CI)

Kontinuierliche Übermittlung