Kernprinzipien des Continuous Delivery: "Your software should always be releasable!"
Sebastian Meyen sprach auf der JAXconf 2012 mit Jez Humble von Thoughtworks über die Konzepte hinter Continuous Delivery. Seine Kernaussage: “Your software should always be releasable!”
Das könnte Sie auch interessieren!
Kommentare
"Java EE und Microservices – rein technologisch spricht nichts gegen dieses Duo"
"Ich bin keinesfalls der Meinung, dass man immer Microservices einsetzen sollte"
Domain-driven Design im Experten-Check: Wie kann DDD in die Praxis umgesetzt werden?
"Man braucht einen Tag, um von DDD zu profitieren, aber ein ganzes Leben, um es zu meistern" [Interview mit Jimmy Nilsson]
DDD-Patterns – Bausteine für erfolgreiches Domain-driven Design
Kurzer Hinweis: JSON-P meint hier ein anderes JSON-P, nämlich das JSON Processing API (https://json-processing-spec.java.net/). Warum sich der JCP hier — sowie auch bei JSON-B —... MicroProfile 1.0 ist da: Der neue Microservices-Standard für Java EE
Hi Sven, ja das stimmt! Wenn sich ein Markenname erst mal etabliert hat, sollte so eine Namensänderung wirklich gut überlegt sein... Da die neuen Pixel-Geräte... Planet Android: Android Studio 2.2, Apps schreiben in Ceylon und was hinter "Made by Google" steckt
Unabhängig vom sonstigen Inhalt des Artikels, finde ich es erschreckend, dass selbst heute noch Experten Werte wie "Umsatz", die ja gemeinhin Geldbeträge darstellen, als Double... Experten-Check: Was ist "schöner Code" für Java-Entwickler?
Maschinelles Lernen in der Praxis: Von Computerspielen lernen und Mode
Bitcoin Flipping: "In Zukunft wird die Blockchain im Bereich Künstliche Intelligenz Anwendung finden"
"Python ist heute die populärste Programmiersprache für maschinelles Lernen"
Maschinelles Lernen in der Praxis: Von Gurken und Horrorfilmen
Machine Learning mit WEKA: Alles begann, als Java noch in Kinderschuhen steckte
Wiederverwendbare Komponenten mit Angular 2.0 – Deep Dive
Zehn SQL-Tricks, die du nicht für möglich gehalten hättest [Video]
Not your Daddy's Language: Neue Anwendungsbereiche für Sprachen und IDEs
Wie sieht ein Microservices-Technologie-Stack aus?
DDD & REST - Domain Driven APIs für das Web
AngularJS auf einen Blick: Was das Angular-2-Release zu bieten hat
Wer entscheidet bei Ihnen über Software-Architektur?
- Es gibt bei uns zwar keine dezidierten Software-Architekten. Für Architektur-Entscheidungen sind aber immer gewisse Team-Mitglieder zuständig, die dann auch an der Umsetzung beteiligt sind. (33%, 125 Votes)
- Für wichtige Architektur-Entscheidungen sind bei uns dezidierte Software-Architekten zuständig. Die Entwickler-Teams setzen die Vorgaben dann um. (25%, 92 Votes)
- Software-Architektur wird bei uns eigentlich kaum diskutiert. Wir machen das meiste intuitiv. (19%, 70 Votes)
- Regelmäßig wird bei uns das gesamte Entwickler-Team in wichtige Architektur-Entscheidungen einbezogen. (14%, 54 Votes)
- Die wichtigsten Architektur-Entscheidungen werden bei uns zentral vom Management getroffen. (7%, 26 Votes)
- Für Architektur-Entscheidungen werden externe Consultants ins Unternehmen geholt. (2%, 7 Votes)
Loading ...
"Bei selbstorganisierten Teams geht es nicht nur darum, eine Wohlfühlkultur zu schaffen"
"Microservices reduzieren Komplexität nicht"
Prometheus: Das Monitoring-Tool für Microservices
Infrastruktur neu denken: "Solche Produktivitätsgewinne haben wir bisher noch nie gehabt... nicht einmal gedacht"
"Devs und Ops sollten sich gegenseitig als Kunden betrachten"
"Es ist nun sicher, in die Cloud zu wechseln"