Delivery to Operations – DelOps approach by DerSalvador
DevOps across two companies (solution provider-solution consumer relationship)
When looking at the current disruptive technologies like Docker and other container virtualization technologies helping developers to be more productive and have enabled the DevOps movement at all in the first place it might be obvious that the focus lied on the agile part in DevOps first. Another objective of this movement certainly is to convince system operators to develop infrastructure code in an agile test-driven and iterative manner. So it is no surprise that other use cases which do not involve the Dev part in DevOps have not been in focus until the time being.
DelOps Approach – Process View
The typical and official build and deployment pipelines start on premise, making it easy to map their output artifacts and their content to an internal infrastructure through plugins, built-in or extension functionalities of the build tool in use. A Nuget package from Microsoft or an EAR file from JBoss are good examples. However, how can volatile contents of third party deliveries from external software suppliers be embedded in the internal DelOps processes in a similar way? Some potential solutions can be found in popular design patterns coming from software engineering. By using the adapter pattern, a DSL (Domain Specific Language) or the transformation approach by XSLT, a standardized processing of volatile content of deliveries can be introduced here. We started an open source initiative as DerSalvador GmbH to create a standard protocol in describing (third-party) package contents. The solution consists essentially of an XML-DSL or JSON-DSL which is designed for generic delivery contents. This DSL is of course extensible according to the specific requirements. It includes not only typical DevOps aspects, but also all business and operating processes such as change and release management, monitoring, security and automated provisioning of infrastructure. The goal is also to integrate these processes into the entire DevOps deployment process in an automated form. For example, an ITIL Standard Change could be automatically detected, the security checks, and the automated UAT test executed, so that a production deployment of external packages could take place in minutes. Nowadays the introduction of a standard change in private banks into production still takes often about 2 days. These bottlenecks are found in companies with a rigid change and release management culture and a DevOps-unfriendly environment.Our DelOps approach can achieve deployment Lead-Times similar to successful Fin-tech Startups even for traditional Private Banks.
DelOps Approach – Architectural View with Docker
