Although Micro Focus Deployment Automation is not intended to be a full-on Release Management solution like Micro Focus Release Control, it does have some lightweight features for scheduling and preventing deployments. Not everyone is aware of these capabilities and when to use them however, so I will endeavour to expand on them here.

Process execution scheduling

The execution start time of any Application Process or Deployment Package can be scheduled from the Deployment -> TImeline view. The Schedule button at the top right allows you to schedule the execution of a particular process or package into an environment on a particular start date and time - as in the screenshot below:

Note: for a Deployment Package the environment might have already been pre-selected in the process so environment selection is skipped.

You can also make the schedule recur daily, monthly or weekly - this is useful for scheduling something like overnight regression tests or similar processes you want to execute repeatedly overnight.

Inter-process execution scheduling

Another feature that people might not be aware of is that you can also schedule steps inside a process by making use of the Process Sleep step. In this step you can select "Sleep specified time" and enter a number of seconds or "Sleep until date" in which you can specify the date and time to wait until before carrying on execution. An example is shown below:

This feature can be particularly useful in the context of a Deployment Package process whereby you could schedule the deployment of multiple applications at specifid times for each or for deployment to multiple environments - maybe even environments for different locations and timezones around the world. 

Blackouts

Blackouts can be used to prevent the execution of deployment processes at execution time or scheduling time. They are useful for representing "Change Freezes" - for example many organisations prevent deployments to Production environments at the end of of month or end of financial year. There might also be cases where applications are processing or mining large amounts of valuable data over a period of time and you don't want to suddenly interrupt this by deploying a new version.

There are a number of blackouts that can be defined:

• Application Environment Blackouts
  These prevent a single Application being deployed to one of its Application Environments between a start and end date/time.
• Global Environment Blackouts
  These prevent any Applications being deployed to a specific Global Environment between a start and end date/time.
• Resource Blackouts
  These prevent any deployment being executed to an individual Resource between a start and end date/time.

An example of Blackout scheduling is shown below:

Unlike process execution Scheduling, Blackouts can not be scheduled repeatedly - although this is a feauture which should be implemented soon.

Obviously process execution Scheduling and Blackouts work together. For example if you tried to schedule the deployment of an Application to an Environment during a Blackout period you would receive a message similar to the following:

Scheduling and Blackout Visualisation

Deployment Automation also visualises all of these Schedules and Blackouts in a number of places, for example from the Deployment -> Timeline view the next month might look something like this:

They can also be visualised in the Timeline view of Global Environments - useful if you were an Ops user and just wanted to keep a view accross all Applications at the Production environment level. (you can also schedule at the Global Environment level as well). The next scheduled deployment for Applications and Deployment Packages are also visualised on their home Activity page.

Finally, scheduling also works nicely with Deployment Automation's lightweight Approval mechanism. If deployment to an environment requires one or more approvals, you can schedule the deployment - so that the approvers know when it is going to happen - then they can approve or reject the deployment any time before the start time. If they do not approve it before the start time then the process is cancelled.

And a few final words...

As you can see their are quite a number of powerful and useful features here but it should also be stated what the limits are and where you should venture into a more powerful process oriented solution such as Micro Focus Release Control. From a scheduling perspective Deployment Automation does not have the concept of Deployment Windows - only allow deployment between certain start and end times - or Environment Reservations - where users can reserve particular Environments so that only they can deploy to them at certain times. Obviously there is also no notion of a "Release" as an end-to-end process in Deployment Automation  so it doesn't gather all the milestones, checkpoints and dependencies that Release Control does.