Hi Rachel - I'll try to explain it. It looks a little more complicated than it actually is. We've found this has worked well in our instance.
Our schedule requirement was slightly more complicated than simply saying the first Thursday of the month because our changes were dependant on other changes. Specifically I implemented this pattern for scheduling Server patching each month, so we needed a scenario where we get the patches into the repositories and update our patching-test servers in the first couple days of the month, then we patch our dev/test servers, then QA/Performance, then PROD instances. So, depending on what day of the week the first of the month falls on determines which days the server gets patched. In the end, we couldn't say Always run this on the first Thursday, because if the first of the month started on a Thursday, we needed to get the repositories updated and the initial patch testing servers upgraded. However, if the first of the month is Sunday thru Wednesday, we open the ticket for the initial repository update on the 1st, then set the first set of "real" server patches on the first Thursday.
Below is an example of the driver table I created for this process:
The way the process works is... near the end of the month, a scheduled job runs and processes all the rows in this table and create appropriate change requests for the following month. It does the folllowing:
1) Open a change request, applying the template listed in the "Template for Change Form" field. This fills in most of the standard fields and also allows flexibility to use different templates for different types of changes if desired.
2) The "Additional Details" field gives additional information above and beyond what's available in the template. This gets appended to the Description field in the change_request.
3) Server List creates the Affected CI list. (It may have been more appropriate to called this "CI List" if we were planning to use it with something other than servers)
4) The fields named after days of the week are basically read as "If the first of the month is a <field label> set the planned start date of the change to the <field value> of the month. So, if the first of the month is a Sunday, in our example, the planned start date would be the 18th of the following month. But, if the first of the month is on a Friday, the planned start date would be on the 20th.
5) The start time and duration fields of this table are used to drive the planned start date's time and planned end date on the change_request form. Using duration here allows for easily handling changes that cross dates.
Basically, everything that is consistent for all changes is kept in the template, and anything that changes is in this driver table. So, our template currently assigns all of these tickets to the same assignment group and person, but if we wanted that to be more flexible I'd pull that out of the template and add it into this table and update the scheduled job to apply that data into the change_request.
Let me know if you still have questions.
