Close

Unterschiede zwischen Continuous Integration, Delivery und Deployment

Lerne die Unterschiede zwischen diesen Continuous-Verfahren kennen.

Sten Pittet headshot
Sten Pittet

Contributing Writer


CI und CD sind zwei Akronyme, die häufig in modernen Entwicklungsverfahren und DevOps verwendet werden. CI steht für Continuous Integration, eine grundlegende Best Practice von DevOps, bei der Entwickler Codeänderungen regelmäßig in einem zentralen Repository mergen, in dem automatisierte Builds und Tests ausgeführt werden. CD kann jedoch entweder Continuous Delivery oder Continuous Deployment bedeuten.

Welche Unterschiede bestehen zwischen Continuous Integration, Continuous Delivery und Continuous Deployment (CI/CD)?


Continuous integration

Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch.

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

Continuous delivery

Continuous delivery is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage.

This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button.

In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

Lösung anzeigen

Hochwertige Software entwickeln und ausführen mit Open DevOps

Related material

What is the DevOps pipeline?

Continuous deployment

Wie stehen die Verfahren miteinander in Beziehung?


Einfach formuliert ist Continuous Integration ein Bestandteil von Continuous Delivery und Continuous Deployment. Continuous Deployment entspricht Continuous Delivery – abgesehen von den automatisch erfolgenden Releases.

Differences between continuous integration, continuous delivery, and continuous deployment

Welche Vorteile bieten die einzelnen Verfahren?


What are the benefits of each practice?

We've explained the difference between continuous integration, continuous delivery, and continuous deployments but we haven't yet looked into the reasons why you would adopt them. There's an obvious cost to implementing each practice, but it's largely outweighed by their benefits.

Continuous integration

What you need (cost)

  • Your team will need to write automated tests for each new feature, improvement or bug fix.
  • You need a continuous integration server that can monitor the main repository and run the tests automatically for every new commits pushed.
  • Developers need to merge their changes as often as possible, at least once a day.

What you gain

  • Less bugs get shipped to production as regressions are captured early by the automated tests.
  • Building the release is easy as all integration issues have been solved early.
  • Less context switching as developers are alerted as soon as they break the build and can work on fixing it before they move to another task.
  • Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.
  • Dein QS-Team verbringt weniger Zeit mit Tests und kann sich auf deutliche Verbesserungen der Qualitätskultur konzentrieren.

Continuous delivery

What you need (cost)

  • You need a strong foundation in continuous integration and your test suite needs to cover enough of your codebase.
  • Deployments need to be automated. The trigger is still manual but once a deployment is started there shouldn't be a need for human intervention.
  • Your team will most likely need to embrace feature flags so that incomplete features do not affect customers in production.

What you gain

  • The complexity of deploying software has been taken away. Your team doesn't have to spend days preparing for a release anymore.
  • You can release more often, thus accelerating the feedback loop with your customers.
  • There is much less pressure on decisions for small changes, hence encouraging iterating faster.

Continuous deployment

What you need (cost)

  • Your testing culture needs to be at its best. The quality of your test suite will determine the quality of your releases.
  • Your documentation process will need to keep up with the pace of deployments.
  • Feature Flags werden zu einem festen Bestandteil des Release-Prozesses wichtiger Änderungen, um die Abstimmung mit anderen Abteilungen (Support, Marketing, PR etc.) sicherzustellen.

What you gain

  • You can develop faster as there's no need to pause development for releases. Deployments pipelines are triggered automatically for every change.
  • Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.
  • Customers see a continuous stream of improvements, and quality increases every day, instead of every month, quarter or year.

One of the traditional cost associated with continuous integration is the installation and maintenance of a CI server. But you can reduce significantly the cost of adopting these practices by using a cloud service like Bitbucket Pipelines which adds automation to every Bitbucket repository. By simply adding a configuration file at the root of your repository you will be able to create a continuous deployment pipeline that gets executed for every new change pushed to the main branch.

A continuous deployment pipeline with Bitbucket

Going from continuous integration to continuous deployment


Wenn du gerade erst mit einem neuen Projekt ohne Benutzer beginnst, ist es möglicherweise am einfachsten, jeden Commit in der Produktion bereitzustellen. Du kannst sogar damit beginnen, deine Deployments zu automatisieren und deine Alpha-Version in einer Produktionsumgebung ohne Kunden zu veröffentlichen. Dann kannst du deine Testkultur verbessern und sicherstellen, dass bei der Entwicklung deiner Anwendung mehr Code abgedeckt ist. Wenn du dann bereit bist, Benutzer einzuführen, verfügst du über einen großartigen Continuous-Deployment-Prozess, bei dem alle neuen Änderungen getestet werden, bevor sie automatisch in der Produktion veröffentlicht werden.

Wenn du jedoch bereits eine bestehende Anwendung für Kunden hast, solltest du das Ganze langsamer angehen und mit Continuous Integration und Continuous Delivery beginnen. Beginne mit der automatischen Ausführung grundlegender Unit-Tests. Mit komplexen End-to-End-Tests musst du dich vorerst noch nicht auseinandersetzen. Stattdessen solltest du versuchen, deine Deployments so schnell wie möglich zu automatisieren und eine Phase zu erreichen, in der Deployments in deinen Staging-Umgebungen automatisch durchgeführt werden. Denn durch automatische Deployments kannst du deine Energie für die Verbesserung deiner Tests aufwenden, anstatt ständig deine Arbeit zu unterbrechen, um einen Release zu koordinieren.

Sobald du in der Lage bist, täglich Software zu veröffentlichen, kannst du dich mit Continuous Deployment befassen. Vergewissere dich aber zunächst, ob das übrige Unternehmen ebenfalls dafür bereit ist: Dokumentation, Support, Marketing usw. Diese Funktionen müssen sich an die neuen Release-Intervalle anpassen. Es ist wichtig, dass sie alle wesentlichen Änderungen berücksichtigen, die sich auf die Kunden auswirken können.

Lies unsere Leitfäden


Read our guides

You can find some guides that will go more in depth to help you getting started with these practices.

Sten Pittet
Sten Pittet

Ich bin seit 10 Jahren in der Softwarebranche tätig und hatte schon verschiedene Positionen inne, unter anderem in der Entwicklung und im Produktmanagement. Nachdem ich in den letzten 5 Jahren bei Atlassian an Entwickler-Tools gearbeitet habe, schreibe ich jetzt über das Erstellen von Software. In meiner Freizeit feile ich zusammen mit meinem Kleinkind an meinen Kompetenzen als Vater.


Share this article

Recommended reading

Bookmark these resources to learn about types of DevOps teams, or for ongoing updates about DevOps at Atlassian.

Devops illustration

DevOps community

Devops illustration

Blog lesen

Map illustration

Get started for free

Sign up for our DevOps newsletter

Thank you for signing up