Things become way more complicated when more than one application and development team is involved in implementing a feature and moreover when multiple of these application-overlapping features are being worked on in parallel and thereby modifying the same components. But as this would stay within the boundaries of one development team it would be relatively easy to organize that all components are deployed simultaneously.
#DEPLOYIT VS PUPPET CODE#
In fact, even if a feature can be implemented by only modifying components within one application at least some degree of orchestration is necessary (a good example is a modification in the source code and one in the database schema). If the component would be deployed on different days it would break or at least disrupt the applications. This seemingly innocent fact had a rather big consequence: it resulted in the need for a release process that is capable of deploying the modified components of each of these impacted applications in the same go, in other words an orchestrated release process. This would not only require a modification to the application itself but also to the central data hub and to the application that receives this information from the outside and acts as the owner of this information. Simple example: an application needs to display additional information about a financial instrument. (For the sake of completeness, here are the links to the introduction and an analysis of the problems) A need for orchestrationĪs a small reminder from my earlier posts, the applications in our company were highly integrated with each other and therefore most of the new features required modifications in multiple applications, each of which managed by its own dedicated development team. In this post I will take it one step further and explain how we improved our release management efforts and more specifically why we needed orchestrated releases, how they compare to continuous deployments and how we selected and implemented a tool to facilitate us with these releases. In my previous post I explained how the implementation of a configuration management system allowed us to get a better visibility on the different versions of the components that were built and on the new features they contained.
#DEPLOYIT VS PUPPET SERIES#
Welcome to my fourth and final post in this blog post series on introducing DevOps in a traditional enterprise.
0 kommentar(er)
