As a leading global supplier of intelligent automation solutions KUKA offers its customers everything from a single source: from robots and cells to fully automated systems and their networking in markets such as automotive, electronics, general industry, consumer goods, e-commerce/retail and healthcare.
The Challenge
KUKA has used a Salesforce CRM platform since 2016. Salesforce helped streamline their business processes in many ways, yet KUKA began to realize that there was still one area, in particular, that was struggling - their DevOps sector. Their release setup consisted of one org, two sandboxes, and a relatively smaller team, yet frustrations with the process were starting to arise.
“It was a very tough time to assure a smooth deployment, as oftentimes errors or issues would occur. It was challenging," says Daniel Stangl, Deployment Manager/Salesforce Administrator at KUKA.
Prior to Copado, KUKA managed their release process through the use of JIRA. This process consisted of creating user stories, followed by developers manually commenting on which APEX component got modified and tracking which one should be part of the next deployment. At the end of the three-week sprint, the team would take all named components out of the JIRA user stories and then start the deployment, with changesets or by files with the workbench. This resulted in the occurrence of errors, as code had to be verified manually, and sandbox refreshes would cause the need for manual intervention and delay the deployment. This meant there was no real quality control or verification method, resulting in numerous errors and time lost, many times in the form of several hours or days.
“Sometimes we needed a refresh of our sandboxes after a production deployment, which meant 5-6 working days gone and the entire development team was blocked from doing any new work," explains Stangl.
To add to the growing frustrations and complexity of the setup, KUKA did not have a source of truth. This meant there was no version control, which resulted in frequent overwrites. This was further exacerbated by the lack of visibility and transparency, which only further increased the chance of error and loss of time. The team at KUKA knew this process could not continue and that something needed to change in order to be able to continue leading the charge in the intelligent automation industry. KUKA began evaluating DevOps tools.
The Solution
KUKA began looking at DevOps tools as a way to solve their current situation and decided to go with Copado in 2017. Copado, the number one Native DevOps Solution for Salesforce, rose up above other vendors for two specific reasons. The first was due to its native functionality, which meant the team could immediately begin working on it. The second reason was Copado’s integration with third-party DevOps tools, such as JIRA, which would allow them to seamlessly integrate all their current work directly into the tool.
As soon as KUKA implemented Copado, the team began to see an immediate lift and impact. KUKA began with the Copado - JIRA integration in order to get all their JIRA user stories synced to create user stories in Copado. This meant that they began to change their process, as individual code or metadata changes no longer needed to get manually named on the JIRA user stories, as Copado took care of this automatically by having each user story represent any changes due to metadata. This immediately saved the team countless hours that had previously been spent manually tracking. In addition, the “add metadata” functionality now references the named component and the component itself gets automatically retrieved from the org. This meant that the team now has an overview of all touched components and can deploy based on user stories from org to org.
“We finally had an overview of multiple touched components and the flexibility to deploy user story based from org to org," says Stangl. "This was huge.”
After operating with these improved processes for a year and a half, KUKA decided to increase its release sophistication and step it up a notch by implementing the use of GIT as a service provider for the repository. Having a single source of truth allowed the team to create a version control process to even further reduce the risk of overwriting or missing components. This enabled the team to have a complete view of the process and metadata. The team could now easily identify any issues before they arose as they deploy from one sandbox to another. This meant the team gained countless precious hours and dollars back.
KUKA has seen a true transformation in their DevOps processes through the use of Copado. In 2017, before Copado, the team executed around 400 components per deployment and required about 50 manual pre and post deployment steps. In 2018, after early installing Copado, the team saw an increase to 500 components with only 25 manual pre and post steps and then in 2019, an additional increase to 600 components with only 10 manual pre and post manual steps. This shows just how Copado has increased the quality and efficiency of their process.
“With our current Copado setup, we have a full version-controlled process with little manual extra effort (i.e. unsupported metadata)," explains Stangl. "A sprint deployment is done within 2-6 hours instead of 5-6 working days, and we now only refresh our boxes 4 times a year.”
Ultimately, Copado enabled KUKA to implement a true DevOps process and eliminate the need for manual intervention. Copado brought with it a litany of benefits including a source of truth, version control, automation, increase in velocity and quality control. By adopting Copado as their DevOps tool, KUKA has seen both an increase in their velocity and quality of its releases. Copado enables them with the tools and visibility needed to stop errors before they arise, which, ultimately culminates in an improvement in user satisfaction.
“Copado helped us to right away identify potential conflicts and provide merge suggestions," concludes Stangl. "The auto-resolving functionality is already solving the most of all conflicts and only merge problems get into the scope. As the repository is the source of truth and stores each commit in different versions, we can see character by character or line by line what has been changed and what will get into a feature branch for deployment.”
