
LS telcom
Release automation for complex spectrum management software & replacement of Automic Release Automation (ARA)
Challenge
- LS telcom's spectrum management software is used by customers in various individual configurations. The software is released by LS telcom directly into development, testing and other reference systems.
- Differences in individual configurations and systems represent a challenge for release automation.
- Automic ARA was used for release automation. Challenges were missing basic functions, complexity of the engine making individual adjustments requiring intense support, all at a relatively high costs, LS telcom sought to replace Automic Release Automation.
Solution
- Release of the software with flexible parameterization for different systems is automated with Cloudomation Engine.
Result
- Highly flexible release automation that takes differences in systems into account.
- All functionality of Automic ARA was reproduced, with significantly lower costs and with a significantly better user experience.
- LS telcom is very satisfied with the cooperation with Cloudomation.
What was Automated?
Migration from Automic ARA
The release and deployment automation previously implemented in Automic Release Automation (ARA) has been completely replaced and expanded.
Individual deployment for each target system
Operators can deploy components to multiple customer systems simultaneously. Each customer environment is slightly different and consists of at least five separate servers, onto which a variety of different components are deployed. The automation accounts for all variations of customer systems and correctly resolves dependencies between individual steps.
Notifications
After a successful update, as well as in the event of an error, notifications are sent to operators.
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:
- Operators login to Cloudomation to start a deployment. To do this, choose from the following options:
- Which component(s) should be deployed: 10+ components are available to choose from
- Where should the components be deployed: 30+ different environments are available to choose from.
- 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.
- Information is read directly from target environments: which components are currently installed in which versions.
- It is checked whether the upcoming deployment is a patch update or a major version update.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- For each component, there are variants of the installation process for Windows and Linux.
- 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.
- It is checked whether certain components that are required for the database migration are available.
- 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.
- Components are reinitialized (restarted). This rewrites configuration files.
- Another recompile Oracle SQL file is loaded and executed.
- Depending on the component, the database is or is not restarted.
- Oracle Forms is restarted.
- JSON files with access data are rewritten.
- Depending on the component, reports are copied.
- Access rights for file systems are set.
- All services are started.
- All web services are polled until all are available.
- If the entire process was completed without errors, the system will be unlocked again and Citrix Login is possible again.
- After a successful update and in the event of an error, notifications are sent to operators.
- 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.
How did we Develop the Automation?
A release expert from LS telcom formulated requirements for an automation expert from Cloudomation, who implemented the release automation step by step in iterative collaboration with the release expert. The release expert tested implemented automations, and handed over further requirements for the automation of additional release variants. Through the interaction of release expertise and automation expertise in close collaboration, the very complex automations could be implemented with high quality.
The total effort required to implement all of the use cases described here took around 100 hours for a Cloudomation Engine expert.
What are the Next Steps?
- Continuous expansion of release automation to automate the deployment of additional components.
- Operators are currently using Cloudomation Engine to start deployment processes manually. In the future, the process should be triggered by creating a Jira ticket.
- Automation of updates for Oracle Forms in various internal and customer systems.
Meet Your New Platform Engineering Tool
Streamline operations, optimize collaboration, and deliver faster. Let’s discuss how our platform can help you overcome challenges and hit your goals.