Recently I've been having a think about what are the downfalls to Endevor and have come up with the following statements.
Statement 1.
In Endevor I have a 'static' lifecycle, it is not easy to change.
Why is it not easy to change?:
- I have multiple repositories (sets of output libraries) for storing my build outputs, one behind each environment in my lifecycle. In-essence this makes an environment physical and not logical.
- Each environment manages itself with little consideration for other environments (one MCF file per environment).
Statement 2.
In Endevor deployments are limited by my lifecycle. I can deploy to an existing local environment in the lifecycle via Move or to a remote environment via ship. Ship is limited to deploying the contents of a package which in turn is linked to the lifecycle.
If I was to start again today what would Endevor look like? Personally I would separate out Build, Deploy & Release.
Build:
- A flexible & completely logical lifecycle.
- A single Repository for Storing outputs - separate from the lifecycle.
- A single database to maintain the relationships between components in the repository, elements and the lifecycle (this is what makes the lifecyce truly logical).
- The generate process would build outputs, add them to the repository and create the relationships in the database.
Remember a lifecycle is just a representation of the development process and not a representation of the physical environments. Physical environments can be created, deleted or re-assigned to a different stage of the development process at any time. They can be local or remote and are more frequently becoming less traditional (for example zDT).
Deploy:
- A single mechanism for deployment.
- Can run multiple processes as part of a deployment (DB2 Bind post process for example).
- Is a single unit of work (deploy 'this' to 'here' where 'this' uses information from the database to identify the components to deploy and 'here' is the target).
Release:
- The ability to orchestrate deployments.
Discuss.