Get started with tasks
A task is an activity in Deploy. When starting a deployment, Deploy will create and start a task. The task contains a list of steps that must be executed to successfully complete the task. Deploy will execute each of the steps in turn. When all of the steps are successfully executed, the task itself is successfully executed. If one of the steps fails, the task itself is marked as failed.
Deploy supports the following types of tasks:
- Deploy application: Deploys a package to an environment.
- Update application: Updates an existing deployment of an application.
- Undeploy application: Undeploys a package from an environment.
- Rollback: Rolls back a deployment.
- Discovery: Discovers middleware on a host.
- Control task: Interacts with middleware on demand.
Deploy periodically stores a snapshot of the tasks in the system so that it can recover tasks if the server is stopped abruptly. Deploy will reload the tasks from the recovery file when it restarts. The tasks, deployed item configurations, and generated steps will all be recovered. Tasks that were failing, stopping, or aborting in Deploy when the server stopped are put in failed state so you can decide whether to rerun or cancel them. Only tasks that have been pending, scheduled, or executing will be recovered.
Deploy can schedule a task for execution at a specified later moment in time. All task types can be scheduled, including deployment tasks, control tasks and discovery tasks.
Schedule a task to any given date and time in the future. To prevent mistakes, you cannot schedule tasks on dates that have passed.
The amount of time that you can schedule a task in the future is limited by a system-specific value, you can always schedule a task at least 3 weeks ahead.
When a task is scheduled, the task is created and the status is set to scheduled. It will automatically start executing when the scheduled time has passed. If there is no executor available, the task will be queued.
Deploy stores the scheduled date and time using the Coordinated Universal Time (UTC) timezone. Log entries will show the UTC time.
When a task is scheduled in relation to your local timezone, you should pass the correct timezone with the call, Deploy will convert it to UTC. In the Deploy GUI, you can enter the scheduled time in your local time zone, and it will automatically be converted.
When Deploy is restarted through a manual stop or a forced shutdown, it will automatically reschedule all scheduled tasks that are not executed yet. If the task was scheduled for execution during the downtime, it will start immediately when the server restarts.
Scheduled tasks are not automatically archived after they have been executed, you must do this manually after the execution has finished.
In Deploy, the task can be archived only after the completion of execution. By default, Deploy will reuse its live database for the archived tasks. Archiving the task can only be done manually as this is required to review whether a rollback is required.
The successfully deployed and archived tasks can be viewed in the Dashboard under the Reports tab on the main menu.
When a scheduled task encounters a failure during execution, the task will be left in a failed state. You must manually correct the problem before the task can continue, or reschedule it.
You can start a scheduled task immediately, if required. The task is then no longer scheduled, and will start executing directly.
You can reschedule a task to any other moment in the future.
A scheduled task can be cancelled. It will then be removed from the system, and the status will be stored in the task history. You can force cancel a task to delete all the task related files and skip all the failed steps.
When using the force cancel option to cancel a task, the task data is removed from the database. If the
workdir on one of the nodes in the active/hot-standby or master/worker setup still contains the task, Deploy displays the task as unknown when it is restored from the
workdir. The task exists in the task engine, but cannot be managed through the Deploy Monitoring view.
To restore the unknown tasks and return a list of Task IDs to the Deploy CLI, execute this method from the Deploy CLI:
Deploy fetches the tasks from all the workers and restores the information for the tasks back to the active repository (database). Resolving the unknown tasks on workers is done based on the missing information in the database for such tasks that exist in the local task repository.
In Deploy, a task can go through the following states:
You can interact with tasks as follows:
- Start the task. Deploy start executing the steps associated with the task. If there is no executor available, the task will be queued. The task can be started when the task is pending, failed, stopped or aborted. Starting a task when scheduled will also unschedule the task.
- Schedule the task. Deploy will schedule the task to execute it automatically at the specified time. A task can be scheduled when the task is pending, failed, stopped or aborted.
- Stop the task. Deploy will wait for the currently executing step(s) to finish and will then cleanly stop the task. The state of the task will become stopping. Due to the nature of some steps, this is not always possible. For example, a step that calls an external script may hang indefinitely. A task can only be stopped when executing.
- Abort the task. Deploy will attempt to interrupt the currently executing step(s). The state of the task will become aborting. If successful, the task is marked aborted and the step is marked failed. The task can be aborted when executing, failing or stopping.
- Cancel the task. Deploy will cancel the task execution. If the task was executing before, the task will be stored since it may have made changes to the middleware. If the task was pending and never started, it will be removed but not stored. The task can only be cancelled when it is pending, scheduled, failed, stopped or aborted. You can force cancel a task to delete all the task related files and skip all the failed steps.
- Archive the task. Deploy will finalize the task and store it. You must manually archive tasks. This is required so you can review the task and determine whether a rollback is required. Archiving the task can only be done when the task is executed.
Note: You can use the Deploy command-line interface (CLI) to work with tasks. For more information, see Deploy command-line interface (CLI).