Continuous Delivery using Release Management Automation
Download as PDF, PPTX14 likes8,093 views
This document discusses release management (RM) best practices and maturity models. It describes the typical RM lifecycle which includes change management, version control, build management, binary repositories, deployment frameworks, environment provisioning, and configuration repositories. The document also outlines a four-level RM maturity model and provides best practices for version control, build management, binary repositories, configuration repositories, and deployment management. Finally, it positions RM as an integral part of the overall application lifecycle management process.
More Related Content
Similar to Continuous Delivery using Release Management Automation (20)
Continuous Delivery using Release Management Automation
- 1. Continuous Delivery using Automated Release Management Contents Introduction Forrester Study Release Management (RM) Lifecycle RM Maturity Model RM Best Practices Application Lifecycle Management (ALM) Lifecycle
- 2. Introduction “Continuous Integration” and “Continuous Delivery” are no alien terms to an experienced IT professional. CI & CD define broad principles to ‘Lean SDLC’ focusing on Lower TCO & Faster TTM. Over a period of time a host of FOSS & COTS tools were born to deliver the promise. You might be thinking “there are tools and hence the problem should be solved at least to a major extent…” Not yet, proceed to the next page to see the Forrester study and its results.
- 3. From the Forrester Report “Five Ways To Streamline Release Management” February 7, 2011
- 4. So why is there a lag between the Science & Practicality? There is no one answer to that question, but the following are some of the important ones… Process Anti-Patterns Complete automation not possible due to Missing Release Management Cycle states Less focus on Deployment compared to Build & Version Control Systems Less Traceability & Operational Transparency The following article is based on a “One Click Release Management Automation” we delivered for a Global Banking giant’s Core Banking system. Based on the success the system is being rolled out to the other 700 projects in the bank… Note: The article covers the ‘Big Picture’, Gaps & Best Practices and doesn’t cover the solution specifics which are confidential.
- 5. RM Lifecycle Change Management Version Deployment Control Framework Management Configuration RELEASE MANAGEMENT Build Repository LIFECYCLE Management Environment Binary Provisioning Repository Deployment Management
- 6. RM Lifecycle 1. Change Management 5. Deployment Management • Bug Fixes • Deployment Request Portal • New Enhancements • Environment Management • Project Tracking • Notifications 2. Version Control Management 6. Environment Provisioning • Branching & Merging • Bare Metal Provisioning • Labeling/Tagging • System Configuration • Versioning • Application Sanity Checks 3. Build Management 7. Configuration Repository • Build Request Portal • Repository Structure • Continuous Integration • Environment specific data • Dependency Management 8. Deployment Framework 4. Binary Repository • Remote Deployments • Repository Structure • Orchestration • External Libraries Integration • Error Handling • High Availability • Reusable Deployment Scripts
- 7. RM Maturity Model RM Landscape • RM fully integrated with ALM Framework RM Automation • ALM Framework integrates with all tools/processes of the ALM umbrella • RM fully integrated with ALM • Provides single dashboard view of Project with Full Traceability and Reports & Analytics Level 4 RM Automation RM Landscape • Versioned Build Outputs • Well defined light weight Release Management Process • Binary Repository • Automated RM Framework using FOSS & Custom Components • Configuration Repository, Build Once Deploy Anywhere • Provides Transparency, Reliability, Predictability, Repeatability R • Portal for Build & Deployment Management & Faster Release Cycles Level 3 O RM Automation RM Landscape I • Fully Automated VCS interactions • Org Level Processes & Tool Stack / Home grown Automation • Fully Templatized Build Automation • Lacks RM concepts like Configuration/Binary Repository, … • Remote Deployment Framework • Somewhat Reliable, lacks transparency to scale for • Error handling & rollbacks in Build & Deployment Continuous Integration/Delivery Level 2 RM Automation RM Landscape • Hard wired Build Scripts • No defined Organization Level RM process • Single machine Deployment Scripts • Less usage of tools & Ad-hoc Automation • Low Repeatability, Predictability & Reliability Level 1 Investment
- 8. RM Best Practices Version Control Best Practices • Check-In – Define a periodic check-in (logical chunks) and refresh policy for your project. Check-in can be as frequent as hourly to daily or completely left to developers as in distributed VCS. Project complexity, quantum of integration effort, team co-location are some critical factors to be considered while taking decision. – Do not check-in binaries files into VCS. VCS should be used for files which get updated, strictly speaking an update to a binary results in a new version (i.e. binaries should be treated read only) • Branching & Merging – Branch only if unavoidable and branch late – Do not create separate branches for individual developers. VCS is not a backup server. – Do not create separate branches for SDLC phases (DEV, ST, SIT, UAT, …). A change to an application results in a new version and a version should be deployable to any environment. A change should not be made for a particular environment. – Define policies for syncing branches. Changes from mainline/trunk to other branches should flow continually, branch to mainline for production releases and child branches to parent branches based on situation. Project complexity, quantum of integration effort, team co-location are some critical factors to be considered while taking decision. • Tagging & Versioning – Label/Tag logical points from which builds are taken for releases – Use a common project structure and naming convention
- 9. RM Best Practices Build Management Best Practices • General – A build should always produce a versioned binary package – Check in build scripts into version control system – An output of a build run should be automatically placed in the binary repository as per the structure – Build Requests should be captured for audit and other uses. Use a web portal as a build management tool. – Schedule periodic automated builds with the help of CI tools • Modularize – Break down your project into components and build only changed components & their dependencies – In the J2ee world, use Maven/Ivy to manage component dependencies – Break down your build script into reusable templatized components. Do not hard code.
- 10. RM Best Practices Binary Repository Best Practices • Should have a defined structure & naming convention • High Availability (e.g. SAN clusters with redundancy) • One Binary Repository for a company/unit, can be geographically clustered with replication for performance • Should support promotion of binaries to SDLC environments (DEV/ST/UAT/…) • Should have automatic redundancy detection and avoidance • Can be realized using products like Archiva, Artifactory or a custom solution on top of the file system • Should only be accessible to the deployment frameworks based on right ACL • Should only support file creation, update/delete should not be provided Configuration Repository Best Practices • Should have a defined structure & naming convention and match that of a binary repository • Should be realized on top of a version control system • One Configuration Repository for a company/unit, can be geographically clustered with replication for performance • Should only be accessible to the deployment frameworks based on right ACL
- 11. RM Best Practices Deployment Management & Deployment Framework Best Practices • Deployment Management – Deployment Requests should be captured for audit and other uses. Use a web portal as a build management tool. – Capture the revision/version number of the configuration repository at the time of deployment request – Deployment portal should present the deployment options after linking the Binary & Configuration Repository • Deployment Framework
- 12. ALM Lifecycle Testing Requirements APPLICATION LIFECYCLE MANAGEMENT (ALM) • Traceability • Process Automation • Reporting & Analytics Release Modeling Development RM is a part of Application Lifecycle Management