Thanks for your valuable feedback, currently we are populating calendar based on schedule start date and end date and its not configurable like mid-tier calendar.
Let me check with PMs if we can accumulate this change.
very, very sad to hear that this is currently not included.
This is a must for our customers.
For example: Beyond several smaller releases (weekly = agile) there are 2-4 main releases per year, where the really "big" main applications for the core business are effected. A very long planning phase to coordinate all the activities and changes is required. The testing phase (TEST milestone) will last several weeks.
So it's possible, that a release will be deployed at a specific weekend in November 2019 (Friday night to Sunday morning) which is represented by the Deployment Date fields. But the work for the Release is already ongoing several month before. (Schedule Start and End Dates)
It does not make any sense to have an entry for such "long-term" releases from June to November in the calendar. Especially not for dozens of affected services / applications which will all use the November weekend as their deployment window.
This will make the calendar absolutely useless. Thinks of 50+ release entries displayed for every day in the calendar during a 6 month period, though the deployment will take place on a single weekend in November. The "small" weekly releases (agile CI/CD) will simply "disappear" in such an overloaded calendar view.
Users will open the calendar once and never open it again.
So you're using the Scheduled Start Date and Scheduled End Date as the date boundaries for all activity in a release, and not just the intended deployment window. I can see the case here, e.g. based on the documentation: "The release coordinator sets the scheduled, actual, and deployment start and end dates for the release"
However, the thing that slightly concerns me is that the current approach is consistent with collision management... which uses the Scheduled dates, not Deployment dates. Also, in the more verbose ITSM documentation: "Allen reviews the release plan. He opens the Change Calendar and views the current schedule of releases, change requests, and business events for any potential conflicts. He adjusts the start and end dates accordingly". This could certainly be read as being more than just about the deployment date, but also the broader activity you describe, where it might still be important to understand what's going on.
thank you for your reply. Yes, there is room for interpretation of the wording and terminology. But from my understanding of the process (at least in ITIL v3 2011) there is some sort of difference between release and deployment management sub processes.
Blue --> within the Scheduled timeframe
Red --> within the Deployment timeframe
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.
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.
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.
Process Objective: To formally close a Release after verifying if activity logs and CMS contents are up to date.
And only the deployment is really important for conflict assessment (collision detection). Planning or Build Milestone have absolutely no impact here.
So one may ask, why we are not using the scheduled date fields (instead of the deployment date fields) and narrow the timeframe defined there so they will match the deployment window.
The answer is twofold:
1. We need to know from when to when the other sub processes with all their activities are planned and see their progress in relation to the deployment date. And this will inclide the activities after go live (deployment to production).
2. And it is there. BMC has implemented it that way. And it makes sense.
So we think:
For a release with all it's milestones it absolutely makes sense to have the two different times frames
- The overall plan represented by the Scheduled Startdate --- Scheduled End Date
- The Deployment windows represented by the Deployment Start Date --- Deployment End Date
This has been in ITSM since the Release Management module has been introduced.
In the "old" Mid-Tier calendar customers were able to choose which of the two fits best to their specific needs.
And they were able to configure it accordingly.
For me it is not the prefered way to nail this down to only one way into the code. This has to be configurable, as it has been before.
there is another reason, why we need both timeframes. It's they way BMC implemented date checks. And it is correctly implemented.
If you try to add a Change Request to an existing release Record and the Scheduled Dates of the change are outside the Scheduled Dates of the release, then the Scheduled Dates of the release will be automatically adjusted accordingly.
And this is a correct behavior, because the timeframes of the children (manifest content / release plan) must not lie outside the boundaries of the parent.
Change to add:
Add to manifest in phase Close Down (so after deployment):
If you go forward in the relase process a warning message will appear:
And the Scheduled End Date is adjusted (in this case, for the dates for the change are later than those of the release):
This is absolutely correct.
Seems some sort of hint that Schedule Start Date and Scheduled End Date are not the right fields to define the deployment timeframe.