LS telcom

The release and deployment automation previously implemented in Automic Release Automation (ARA) was completely replaced and extended. For this purpose, an automated process was set up in Cloudomation Engine that includes the following steps:

1. Operators login to Cloudomation to start a deployment. To do this, choose from the following options:
   1. Which component(s) should be deployed: 10+ components are available to choose from
   2. Where should the components be deployed: 30+ different environments are available to choose from.
   3. Which version should be deployed.

      
      Operators can deploy components in multiple systems at the same time.
      Each environment is slightly different and consists of at least 5 separate servers to which a variety of different components are deployed. The automation takes into account all variants of the systems and correctly resolves existing dependencies of the individual steps.

2. Information is read directly from target environments: which components are currently installed in which versions.
3. It is checked whether the upcoming deployment is a patch update or a major version update.
   
   1. The target system is first updated to the next major version. Updates are then applied individually for each patch version. Example: Update from 3.0.2 to 3.5.2: first an update to version 3.5.0 is performed, and then separate updates from 3.5.0 to 3.5.1 and then to 3.5.2.
   2. Deployment processes are determined and carried out separately for each target system. If operators update several systems at the same time, which updates need to be carried out in order to reach the target version is taken into account for each system.
4. Installation files are downloaded from the Nexus repository. System-specific paths are taken into account here, as additional special installation files are created for different operating systems as well as for some customized system and stored in different paths in Nexus.
5. The target system is locked: Citrix Login for customer systems is locked for the duration of the update. Logged in users are logged out of the system.
6. Configuration files are adjusted. This happens depending on which components are updated and includes various changes, such as entering changed ports so that components can communicate correctly with each other after an update.
7. Depending on the component, the respective update process is carried out: Tomcat caches are emptied, .war files are copied into target systems and deployed in Tomcat.
   
   1. For each component, there are variants of the installation process for Windows and Linux.
   2. Patch and major version updates are subject to different checks. Not every web service is always updated during patch installations, but all web services are updated for major version updates.
8. It is checked whether certain components that are required for the database migration are available.
9. Database migration steps are processed. For this purpose, Oracle SQL files are loaded into the Oracle database and executed. Depending on the component, several Oracle SQL files are loaded and executed.
10. Components are reinitialized (restarted). This rewrites configuration files.
11. Another recompile Oracle SQL file is loaded and executed.
12. Depending on the component, the database is or is not restarted.
13. Oracle Forms is restarted.
14. JSON files with access data are rewritten.
15. Depending on the component, reports are copied.
16. Access rights for file systems are set.
17. All services are started.
18. All web services are polled until all are available.
19. If the entire process was completed without errors, the system will be unlocked again and Citrix Login is possible again.
20. After a successful update and in the event of an error, notifications are sent to operators.
21. In the notifications, operators can choose whether the error should be ignored, the process aborted, or a process step should be performed again.

The entire process is carried out and monitored in Cloudomation Engine.

A number of other use cases were also implemented, some of which are called by the overall deployment process:

• Lock and unlock customer systems (lock Citrix login and log out users, and unlock again).
• Stop and start services in customer systems, both in Windows and Linux environments.
• Run Oracle SQL Plus, which allows operators to run Oracle scripts on systems. Operators can interactively specify how errors should be handled.
• Create version report: The current version of components in customer systems is read and a report is created. For this purpose, the version for different components is read either from the Oracle database or from binaries.