5 Replies Latest reply on Jul 18, 2019 8:09 AM by Thomas Hammer

    New Calendar: Which Date Fields are used for Release Records?

    Thomas Hammer
      Share This:


      First: The new calendar is a tremendous leap forward. We have been waiting for it for such a long time.Thank you very much.


      When looking at the used timestamps we are not sure, which ones are used for the release records or how the calendar can be configured.

      On the first look it seems, that the 'Scheduled Start Date' and 'Scheduled End Date' are used, but not the 'Deployment Start Date' and 'Deployment End Date'. Or am I wrong? Then I would be happy to be wrong. Just tell me.


      Please have a look at this discussion. https://communities.bmc.com/thread/120420

      We do not need to see the whole life cycle of a release and the whole timeframe from Draft to Closed. This is a far to large timeframe, which would just fill the calendar without any additional value. In the calendar view we are mainly interested in the Deployment Dates, e.g. the evening or the weekend, when the changes are deployed to the production environment.


      Or can this be configured as in the current Mid-Tier calendar (see above link)?


      Any clarification is highly appreciated.

      Thank you very much

        • 1. Re: New Calendar: Which Date Fields are used for Release Records?
          Jameer Inamdar

          Hi Thomas,


          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.




          • 2. Re: New Calendar: Which Date Fields are used for Release Records?
            Thomas Hammer

            Hi Jameer,

            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.

            • 3. Re: New Calendar: Which Date Fields are used for Release Records?
              Jon Stevens-Hall

              Hi Thomas,

              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.


              Kayla Block, Peter Adams - this might need some thought. If we only showed releases on the calendar in their Deployment date window (rather than "Scheduled dates"), do you feel that'd work?

              • 4. Re: New Calendar: Which Date Fields are used for Release Records?
                Thomas Hammer

                Hi Jon,

                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


                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.


                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.

                • 5. Re: New Calendar: Which Date Fields are used for Release Records?
                  Thomas Hammer

                  Hi Jon,

                  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.