The word “manifest” comes from Transport Industry and it is widely used term there. The term Manifest in Transport industry has the following definition
Manifest: A document listing the cargo, passengers, and crew of a ship, aircraft, or vehicle, for the use of customs and other officials.
The above definition in general applies to almost all industries, with certain refinement and modification in stakeholder and participants. The intent of Manifest remain uniform across verticals i.e. a document which provide a way to assess and answer the below questions
Question Manifest Answers | In Context of Transport(shipping) | In context of IT |
What had been _______? | What had been shipped? | What had been packaged? |
When it is _______? | When it is shipped? | When it is packaged? |
How it is _______? | How it is shipped? | How it is packaged? |
Who _______ it? | Who shipped it? | Who packaged it? |
Where it is _______? | Where it is shipped? | Where it is packaged? |
Fig: Some assessment manifests provide information such as in the above examples to illustrate the context of shipping and IT verticals
The vantage value yielded from manifest files and the ease of cultivating the same made it highly adaptable across multiple industries and verticals.
The intent of this article is to evaluate and consider the usage of Manifest in most vital process of delivering products and software’s to market i.e. Release and Deployment process. With acceptance of agility (Agile software development) in software development life cycles, it’s essential to have an agile process for delivering new feature sets to customers as quickly as possible. These feature sets are the outcome of each sprint.
Release and Deployment is a slightly tricky process. Each potential feature/ship-able component has to go through various interim environments, exhaustive testing and needs to be QA certified before it "Go To Market"(GTM).
The Release and Deployment process can be so cumbersome due to various complexities like dependency identification and resolution, pre-requisites identification and verification, off-time deployments, configuration management w.r.t. components and environments. Traditionally teams don’t have a uniform process or template defining and describing their release and deployment process and in absence of an error or step missed at any stage can create lot of dissonance among interconnected and interdependent systems.
The team responsible and involved in the Release and Deployment process needs to be competent enough to access and audit the system and various sub-systems (system refers here to one or group of interconnected servers logically grouped like grocery portal systems, online payment system etc.) pre and post release to ascertain what it host. The better release teams and admins (Ops team) know their systems better, so they can address any issues or complaints which may come up pre and post release.
In simple equation - the more time you spend accessing what does the system hold, the more time it will take to correct and address a problem, which in its turn will lead to longer outages.
Manifest files address most of the concerns discussed above. CA Technologies is pioneering “Manifest driven Release & Deployment” which provides complete autonomous control to release teams to release across environments uniformly (using templates) and audit system state under release. The reason we recommend to "Manifest: what you release, to cognize what you have and where you stand?" as a guideline. Manifest will benefit you in accessing your system under release at any time in addition it gives you the control to decide what goes in which part of system. Project management teams can access this information to determine where they stand and what they need to change to meet there GTM deadlines.
Some salient features of CA Release Automation w.r.t. Manifest driven Release & Deployment are listed below
- Out Of Box (OOB) Manifest generation assimilating deployment process design
- In built dashboard to monitor health of system during release
- Uniform deployment process adapting to operational change in lieu to data provided via manifest enabling management team to more precisely access system outage timeline during releases
- Auto-saving of used manifest in repository for later reference and reuse
- OOB feature of deployment report and deployment comparison.
- Unique feature of Deployment pipeline to ascertain status of deployment in each environment
Please refer below on how CA Release Automation enables to access:-
What you release?
What you have in your systems or sub-systems?
(Provide information like how many deployments, which deployment failed etc. these reports are can be filtered to users need)
At end I want to conclude with a beautiful quote
“If you don't know where you are going, you'll end up someplace else”
So ask yourself these simple question to determine if you really progressing on journey of well-orchestrated and controlled releases.
- Do you really know what you release and how you release?
- What your current system hold?
- What is expected downtime in your release cycles?
- What is your rollback strategy?
- How many heterogeneous environments you want to orchestrate?
“Ascertain where you stand to estimate where you want to be in how much time!!”