Q1 ) what is release and deployment management ?
Release management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases
Q2) what is scope and objective of Release Management ?
Scope of Release & Deployment Management:
The scope of Release and Deployment Management includes the processes, systems and functions required to package, build, test and deploy a release into production in accordance with the Service Design Package (SDP). This includes handover to the Service Operation lifecycle stage.
Objective of Release & Deployment Management:
The objective is to ensure that there are clear consistent plans that everyone understands and follows, that releases are managed efficiently and effectively through to deployment and use and that the new service and supporting systems are capable of being operated successfully and deliver the agreed service requirements (Utility and Warranty).
Goals of Release & Deployment Management:
The goal of Release and Deployment Management is to build, test and deliver new or changed services successfully into the production environment and use within required timescales and with minimal disruption to existing services.
Q3) what are the daily activities of a Release manager ?
Facilitates release planning meetings with key stakeholders to identify proper sequencing of release packages. Ensures that issues and risks are identified, understood, and dealt with in a manner that mitigates risk to scope and schedule.
Defines and documents the release recommendation for each release and/or change to production. Includes release scope, schedule, deliverables, and roll back plan. Reviews release recommendation with key stakeholders.
Oversees release decisions and processes in terms of the big picture/cross-departmental impacts.
Maintains release management schedule for specific (or assigned) system(s).
Documents and communicates all changes for a release in release notes which are published to both the internal team and the client.
Attends change management such as CABs and deployment planning meetings to collect data and information pertaining to the release.
Q4) What is the branching strategy you used ?
Release Branching: develop on trunk, keep a branch for each release.
Feature Branching: develop each feature in a separate branch, only merge once stable.
Release branches are very useful, and even absolutely required, if you need to maintain several versions of your app.
Feature branches also are very convenient, notably if one developer needs to work on a huge change, while others still release new versions.
So to me using both mechanisms is a very good strategy.
Q5)Explain me one tough scenario you faced and come out of it with brilliance ?
When DR is active , because of production environment is down. Our business partners still will contact production environment which will not work.
To address this specific case for B2B partners introduced a gateway in both Dr and production environment which configured under a load balancer . whatever gateway is up either DR or Production that will contact B2B applications.
Q6) Tell me an improvement you suggested , that saved revenue ?
Moving static content website to CDN , instead of maintaining own private CDN.
Integrating beta testing into regression testing.
Q7) what are the release approaches ?
Phased :
Basically, you have your new feature coded tested and even merged into trunk but not yet deployed to production.
You deploy, and then...
Well, pretty much nothing happens. The new feature doesn't show up for any users. The cause of this isn't a mystery, because you also added code to turn off the feature by default, and you then only turn it on for a small group of users .
In any case, you monitor the group you turned the feature on for (either you simply making sure nothing bad happens like servers becoming unstable, or you are checking that users use the feature, or that the new feature changes user behavior in the way you expect, or ...), and if all goes well you continue to expand the group in 'phases' until it is finally on for all users.
In your next deployment, you can remove the switching code for that feature or change.
BigBang Release:
The new or changed service is deployed to all user areas in one operation.
Big bang option
The new or changed service is deployed to all user areas in one operation.
Phased approach
The service is deployed to a part of the user base initially, and then this operation is repeated for subsequent parts of
the user base via a scheduled rollout plan.
Push and pull
A push approach is used where the service component is deployed from the centre and pushed out to the target
locations. In terms of service deployment, delivering updated service components to all users – either in big bang or
phased form – constitutes push, since the new or changed service is delivered into the users’ environment at a time
not of their choosing.
A pull approach is used for software releases where the software is made available in a central location but users are
free to pull the software down to their own location at a time of their choosing.
As some users will never pull a release it may be appropriate to allow a pull within a specified time limit and if this is
exceeded a push will be forced, e.g. for an antivirus update.
Q7) what are the specific cases that you opted for phased approach?
for features whose testing was not covered under regression cycle
because of time constraints or geographical constraints(say some feature to be behaved in specific way in a country .. during testing few users can be marked as IP zone of that country .. this a test data creation. but not complete testing ).
in these scenarios phased manner is suggested.
Q8) what is the knowledge transfer mechanism after go live ?
Knowledge transfer – This is the activity through which one unit (e.g. group or department) is affected by the
experiences of another. The form of knowledge transfer must suit those who will use it, examples of criteria/examples
that can be used are:
„ „ Learning styles
„ „ Knowledge visualisation
„ „ Driving behaviour
„ „ Seminars, webinars and advertising
„ „ Journals and newsletters
Q9) what is the baseline in the perspective of Release and Deployment management ?
agreed description of the attributes of a product, at a point in time, which serves as a basis for workable artifact [ tag in SVN]
Roll back: application is straight forward ,.. backup or symlink change
for DB , though we took golden copy before release
after release and before rollback transactions will not cover ... if we rollback to previous golden copy.
for that DBAs will run some EODs.. not sure that process
Q10) what is the reporting mechanism ? what do you generally publish as part of RM role ?
-> Release calendar
-> Release status
Q11) what is Definitive Media Library ?
A Definitive Media Library (DML) is a secure compound in which the definitive, authorized versions of software package configuration items (CIs) are stored and protected. A DML consists of one or more software libraries or file-storage areas, referred to as repositories.
Q12) packing structure in a case of build ?
War : Web modules which contain Servlet class files, JSP Files, supporting files, GIF and HTML files are packaged as JAR file with .war (web archive) extension
Q13) what are the release policies ?
The Release Policy represents a set of rules for deploying releases into the live operational environment, defining different approaches for releases depending on their urgency and impact.
The Release Policy typically contains the following information:
Release identification
(Release identification, numbering and naming conventions)
Requirements
(Requirement that only software from the DML may be included in Releases)
Release levels
For each release level, e.g. major, minor, emergency releases:
Definition of release level
Expected frequency
Roles and responsibilities as well as entry and exit criteria for the different stages of the Release and Deployment Management process (these may be modified for specific transitions as the necessity arises)
Approach and guidelines for grouping Changes into Releases
Planning and documentation requirements, e.g.
Minor Release deployment uses the simpler Minor Change Deployment process and is documented in Release Records and Change Records
Major Release deployment requires setting up a formal project with full documentation
Emergency Release deployment requires authorization by ECAB and is planned, coordinated and documented by a Major Incident Team
Guidelines for different approaches to Release deployment
What are the specific conditions which make a certain approach the preferred option, e.g.
"Big-bang" vs. phased deployment
"Push" vs. "pull" deployment
Automated vs. manual deployment
Constraints for Release deployment
Service Level and Operational Level Agreements typically specify availability targets, including allowed windows for maintenance during which the service might be unavailable. Unless Emergency Releases are required, Releases are routinely deployed during these maintenance windows. Release Management therefore needs to translate the service-specific constraints into Release deployment constraints for the systems, applications and other components which are required for the service to be available.
Service-specific Release deployment constraints as defined in the Service Level and Operational Level Agreements
Service A
Allowed frequency of new releases according to Release type
Release windows and constraints (e.g. Saturday 01:00 – 04:00, not in December)
Service B
…
Release deployment constraints for systems, applications and other components supporting the above services
System A
Allowed frequency of new releases according to Release type
Release windows and constraints (e.g. Saturday 01:00 – 04:00, not in December)
System B
…
Preferred mechanisms
(Preferred mechanisms to automate the deployment of Releases)
Q14) Release and Deployment phases and significance ?
Release Management Support
Process Objective: To provide guidelines and support for the deployment of Releases.
Release Planning
Process Objective: To assign authorized Changes to Release Packages and to define the scope and content of Releases. Based on this information, the Release Planning process develops a schedule for building, testing and deploying the Release.
Release Build
Process Objective: To issue all necessary Work Orders and Purchase Requests so that Release components are either bought from outside vendors or developed/ customized in-house. At the end of this process, all required Release components are ready to enter the testing phase.
Release Deployment
Process Objective: To deploy the Release components into the live production environment. This process is also responsible for training end-users and operating staff and circulating information/ documentation on the newly deployed Release or the services it supports.
Early Life Support
Process Objective: To resolve operational issues quickly during an initial period after Release deployment, and to remove any remaining errors or deficiencies.
Release Closure
Process Objective: To formally close a Release after verifying if activity logs and CMS contents are up to date.
Q15) who decides release rollback ? steps to rollback in optimal time ?
Program or project manager will be the decision maker on the release.
Having automation scripts to revert to previous war as described under rollback plan in release deployment plan in case a failure.
When something goes wrong during deployment, there are three general ways in which we can deal with it:
Rollback - revert to using the previous version of the software
Roll-forward - fix it and deploy a new version
Roll-over - try again, maybe it was an intermittent problem
Q16) why CI and CD are essential and how it helps Release Management ?
Continuous integration is being used in Agile release management to speed the time to delivery without sacrificing quality. Executive managers, project managers and development teams can use this guide to help understand and implement continuous integration as part of their release management strategy.
The processes involved in software development such as writing, building, integrating, testing, debugging, and deploying software applications can be very time-consuming and filled with complexity. Continuous integration, by automating and integrating the different parts of these processes that are repeatable, allow development teams to dramatically improve delivery time. At the same time, automation test can execute tests in a fraction of the time of manual test efforts, freeing up testers to do more exploratory testing, ultimately leading to a higher quality product. The whole team is more productive because they are able to focus on the creative parts of the processes that can’t be automated.
Q17)what is the difference continuous deployment and continuous delivery?
Continuous Integration
Continuous Integration is a software development practice in which you build and unit-test software every time a developer checks in new code. This provides Agile software teams the rapid feedback they need to respond to market demands and eliminate problems quickly.
Continuous Delivery
Continuous Delivery (CD) is a software development practice in which continuous integration, automated testing, and automated deployment capabilities allow high-quality software to be developed and deployed rapidly, reliably and repeatedly with minimal manual overhead.
Continuous Deployment
Continuous Deployment is a software development practice in which every code change goes through the entire pipeline and is put into production, automatically, resulting in many production deployments every day.
With Continuous Delivery your software is always release-ready, yet the timing of when to push it into production is a business decision, and so the final deployment is a manual step. With Continuous Deployment, any updated working version of the application is automatically pushed to production. Continuous Deployment mandates Continuous Delivery, but the opposite is not required.
Q18)how CI cnd CD is achieved in your company?
CI : 1 HP
CD : 2HP
Q19)what is release calendar and how do you measure and publish progress of release on golive date?
The following table provides a template for a release schedule
Release #: This is the release number. This will be allocated either manually by the
Release Manager or automatically by an IT service management tool.
Release type: This defines the type of release. For example: major, significant, moderate,
minor, emergency, etc.
Description: A brief description of the release will be listed.
Status: Shows the current status of the release. For example: pending release,
released, installed, activated.
Approval status: This column shows the current approval status of the release. For example:
pending approval, approved, under review, etc.
Risk level: The risk level will indicate the risk of the release to the business. A high risk
would indicate that the release, if unsuccessful, will impact immensely on the
organization itself.
High, medium and low.
Priority: Priority is used to sort out which releases will occur first. This will be a
constant changing value, especially as the needs of the business may change.
of high, medium and low.
Performed by: Shows who will actually be performing the release.
Planned start date: The planned start date for starting the release.
Planned end date: The expected end date for the release.
Release date: The actual day that the release will be released into the IT infrastructure
Q20) who is held responsible for project delay?
unrealistic timeline
judgement error
client response time
work load on other projects
complexity of the project
loss of employees
