continuous delivery using release management automation
DESCRIPTION
TRANSCRIPT
![Page 1: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/1.jpg)
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
![Page 2: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/2.jpg)
“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.
Introduction
![Page 3: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/3.jpg)
From the Forrester Report “Five Ways To Streamline Release Management” February 7, 2011
![Page 4: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/4.jpg)
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.
![Page 5: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/5.jpg)
Change Management
Version Control
Management
Build Management
Binary Repository
Deployment Management
Environment Provisioning
Configuration Repository
Deployment Framework
RELEASE MANAGEMENT LIFECYCLE
RM Lifecycle
![Page 6: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/6.jpg)
1. Change Management
• Bug Fixes
• New Enhancements
• Project Tracking
2. Version Control Management
• Branching & Merging
• Labeling/Tagging
• Versioning
3. Build Management
• Build Request Portal
• Continuous Integration
• Dependency Management
4. Binary Repository
• Repository Structure
• External Libraries Integration
• High Availability
5. Deployment Management
• Deployment Request Portal
• Environment Management
• Notifications
6. Environment Provisioning
• Bare Metal Provisioning
• System Configuration
• Application Sanity Checks
7. Configuration Repository
• Repository Structure
• Environment specific data
8. Deployment Framework
• Remote Deployments
• Orchestration
• Error Handling
• Reusable Deployment Scripts
RM Lifecycle
![Page 7: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/7.jpg)
RM Landscape
• RM fully integrated with ALM Framework
• ALM Framework integrates with all tools/processes of the ALM umbrella
• Provides single dashboard view of Project with Full Traceability and
Reports & Analytics
RM Landscape
• Org Level Processes & Tool Stack / Home grown Automation
• Lacks RM concepts like Configuration/Binary Repository, …
• Somewhat Reliable, lacks transparency to scale for
Continuous Integration/Delivery
RM Landscape
• Well defined light weight Release Management Process
• Automated RM Framework using FOSS & Custom Components
• Provides Transparency, Reliability, Predictability, Repeatability
& Faster Release Cycles
RM Landscape
• No defined Organization Level RM process
• Less usage of tools & Ad-hoc Automation
• Low Repeatability, Predictability & Reliability
Investment
R
O
I
Level 1
Level 2
Level 3
Level 4
RM Automation
• Hard wired Build Scripts
• Single machine Deployment Scripts
RM Automation
• Fully Automated VCS interactions
• Fully Templatized Build Automation
• Remote Deployment Framework
• Error handling & rollbacks in Build & Deployment
RM Automation
• Versioned Build Outputs
• Binary Repository
• Configuration Repository, Build Once Deploy Anywhere
• Portal for Build & Deployment Management
RM Automation
• RM fully integrated with ALM
RM Maturity Model
![Page 8: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/8.jpg)
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
RM Best Practices
![Page 9: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/9.jpg)
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.
RM Best Practices
![Page 10: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/10.jpg)
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
RM Best Practices
![Page 11: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/11.jpg)
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
RM Best Practices
![Page 12: Continuous Delivery using Release Management Automation](https://reader034.vdocuments.us/reader034/viewer/2022051513/547a02b1b37959582b8b48de/html5/thumbnails/12.jpg)
Requirements
Modeling
Development
Release
Testing
APPLICATION LIFECYCLE
MANAGEMENT (ALM)
• Traceability
• Process Automation
• Reporting & Analytics
ALM Lifecycle
RM is a part of Application Lifecycle Management