CI/CD for a ServiceMax Field-Service Solution at GE Healthcare

The challenge

GE Healthcare was continuously changing its ServiceMax field-service solution, built on Salesforce, along with other areas of its Salesforce org, to improve how field engineers plan visits, travel between sites, write service reports and bill for their work. The build was done by an offshore vendor team of ~30 developers working in 3 parallel streams, supervised by an internal EU-based team.

Because of regulatory requirements, releases were not frequent but controlled, monthly or quarterly. A large release took days, most of them spent troubleshooting: components went missing between orgs, deployments failed halfway, and nobody had a clear view of test coverage until something broke.

What I did

I joined GE in-house at the Kraków Center of Excellence as an internal developer. My job was to work with the developers and the internal team to remove development and support blockers and make delivery predictable.

A few months after joining, I took on the initiative to build a proper CI/CD process. The previous process was largely manual: developers sent their own package.xml files, someone merged them by hand, retrieved the components and deployed them with Ant and the ServiceMax Migration Tool. After the change, every change went through source control in GitHub Enterprise, and deployments ran through automated pipelines using Ant and the Metadata API, instead of being assembled by hand. We ran two proofs of concept, on Bamboo and on Jenkins. Jenkins proved the better fit, and we stayed with it. ServiceMax configuration deployments stayed manual, with the ServiceMax Migration Tool. Once releases were scripted, they became repeatable, and the missing-component problem almost completely disappeared. Before, a single deployment run took 2-3 hours and had to be restarted from scratch whenever someone forgot to add a component or merged badly, and those restarts made up 30-40% of the delay on a large release. I also organized the manual pre- and post-deployment steps, so they no longer depended on someone remembering them.

Then I made quality visible. With Gearset I monitored test coverage and test failures across all orgs, so problems surfaced before release day rather than during it. Gearset also exposed drift between orgs: components that existed in one org but not another, or had different last-modified dates. I reviewed code from the vendor teams and worked directly with 4-5 of their developers on how to build and ship, while working with the system architects on solution choices.

I owned production deployments end to end, and alongside the process work I built custom functionality in Salesforce and ServiceMax.

The result

Large release deployment ~2.3x faster: from 2 days release over the weekend to 6-8 hours
Restarts caused by missing components almost completely eliminated, recovering about 27% of release time
A delivery process the 3 vendor streams shared, instead of each doing it their own way

System landscape

Layer	Components
Clouds & Packages	Service Cloud, ServiceMax, Salesforce Platform
Technologies	Apex, Visualforce, REST integrations, Administration
CI / CD	Jenkins, Bamboo, Ant + Metadata API, ServiceMax Migration Tool, Bash scripting, GitHub Enterprise, Gearset

Team & duration

~1 year, 06/2016 to 05/2017. Offshore team of ~30 developers in 3 streams, plus architects, admins and QA. I was the in-house engineer supporting the development streams on technical quality and owning DevOps and releases, as part of the internal team of BAs and architects.