Deployment of processes to production
Once the UAT phase has been accepted the process is ready to be deployed in the production environment. From this point, the process will work on 100% of the cases and can’t be amended without a formal Request for Change.
The Implementation Plan details the plan to be followed during the implementation of the project. It defines the tasks to be covered before, during and after the implementation events, including those tasks performed by the RPA Team, IT and Operational departments.
The purpose of the document is to:
- Communicate and agree on the detailed implementation approach and schedule.
- Aid planning and resourcing of the implementation events.
- Record and manage implementation dependencies. It is intended for all members of the project team and stakeholders. Please refer to the Blue Prism Implementation Plan template for details of the information captured within the plan.
On rare occasions, the production environment may cease to function as expected and an emergency change may be required. For example, a system screen may have changed without prior notice.
For emergency changes, the same controls apply as for any other process changes, the difference being the time in which the changes are done and deployed. A Request Deployment Form can be completed and authorised for emergency changes.
Note: If an emergency change is required to a process that has different versions in the configuration/UAT/Live environments, the change may need to be done and tested in each environment. This is opposed to the usual method of changing in the configuration environment and then migrating.
Some changes to a process may not require any changes to how a process works or to any of its system interfaces. They might only be relevant to the production environment. For example, the network folder to obtain a spreadsheet or the URL to use for an intranet application may change. Such simple configuration changes are only relevant to the production environment and will therefore not be done in the Configuration or UAT environments. A Deployment Request should still be filled in explaining the change and authorised.
A request is made to export the process and its dependent objects and work queues to the Blue Prism Production environment. On successful migration a final check is performed to ensure that all required objects, systems, and work queues can be accessed by the process.
Once a new process or a process change has passed, User Acceptance Testing, deployment into the production environment can be planned and scheduled. A Request Deployment Form should be filled in.
The following information should be completed:
Target Date: This date should take into account when the change is required in production, and any business, system, or environmental pre-requisites.
Change Detail: This should be a brief description of the change and include all processes, sub-processes, and business objects that have been modified.
Description of Testing and Acceptance Criteria: The UAT exit report and any additional testing information should be noted.
Environment Changes Required: Any changes or new requirements in the production environment should be noted here. If required, a separate request should be raised with IT for these changes to be done.
Resource Dependencies: Details of any new or changed systems, services, or network settings should be noted here. If required, a separate request should be raised with IT for these changes to be done.
Authorisation: The deployment request should be signed off by those who have the authority to do so. For example, this may be nominated representatives from the Automation Team, the Business Area, and IT.
If a process has been correctly deployed, the likelihood of any negative effects on processes already in the production environment should be negligible. However, a contingency plan should exist. This will ensure there will be minimal impact on live processes if the deployment has an unexpected effect on the production environment.
The following steps may be taken as a contingency if there is a negative impact:
- Emergency Changes: If the deployment has been unsuccessful due to a minor oversight, it may be acceptable to do an emergency change to fix the issue.
- Reversal of deployment: If the deployment has been unsuccessful and is affecting the running of business critical processes, the changes may be reversed out of the production environment.
Operational Contingency Document
The Operational Contingency Document is updated with details of what action should be taken and when, in the event of the processing being unable to run.
Operational Process Control Document
The Operational Process Control Document is updated with details of what actions should be taken by the operations team to successfully complete a case where a Business Referral or System Exception is generated.
Environment Description Document
An update to the Environment Description Document may be required if new systems/resources have been installed or any other change to the configuration was required to facilitate the process.
Operational Handbook
The Operational Handbook is updated to describe how a process is to be started or restarted.
BAU Support Policy
It is essential that a Service Wrapper is implemented for the live Blue Prism processes to ensure smooth day to day running of the automated processes and to prevent the processes from decaying as systems/business processes evolve. The support policy provides the guidelines on the optimum Service Wrapper for Blue Prism
Deployment Checklist
A new or amended process that has followed the Delivery Methodology and which has a completed and authorised Deployment Request Form, may be migrated into the production environment.
The following steps should be taken during deployment:
- Ensure any live processes or business objects changed by the deployment are not running.
- As part of the Delivery Methodology, all processes with matching interdependencies to the new/amended process will have been regression tested.
- All interdependent processes and business object actions should be evaluated once again in the UAT environment to ensure none have changed since UAT was signed off (i.e. as part of a change to a different process). If any related process or action has changed they must be regression tested prior to deployment, if this has not already been done.
- Any required environmental changes should have been implemented. For example, new email profile and screen resolution changes.
- Any process configuration changes required for use in production should be made such as configuring network directories to use or turning off any ‘test mode’ flags
- Any resource dependencies should be installed such as new web services or internet security certificates.
- Export the new/amended process(es) and related amended sub-processes/business objects from the UAT environment.
- Import into the live environment. For larger deployments the easiest way to do this may be via command line rather than the Blue Prism Export/Import functionality. For any new sub-processes that have not been in the Production Environment before the /forceid command line switch will need to be used to ensure that the sub-process is called correctly from the parent process.
- Post-production installation tests should be done to ensure the migration to the production environment has been successful. This should involve the running and close monitoring of any processes that may have been affected by the deployment.
- Deployment Request - Approved
- Implementation Plan - Approved
- Release Note - Approved
- Deployment Control Policy
- BAU Support Policy
- Operational Handbook
- Operational Contingency Document - Updated
- Operational Process Control Document - Updated
- Environment Description Document - Updated
Visit Blue Prism Help online to find more information on the latest product features, troubleshooting advice and 'how to' guides.