How Cerner Leverages Concourse’s CI Platform for Regulated Environments – InApps Technology 2022

While other attendees at the SpringSource Platform conference in early December were there to hear about the promise of enterprise Java, more widely applicable talks were also on hand. One such talk was given by Greg Meyer and Bryan Kelly from Cerner Corporation, a health care systems integrator. The pair discussed their use of the Concourse continuous integration platform within their highly regulated environment.

Cerner’s journey to adopting Concourse for continuous integration began with a problem statement: To create and deploy quality code officially and as often as needed. This may sound like a generic statement applicable to any team, but the hidden problems behind this came from governance and regulation associated with their industry: health care.

Meyer said that Cerner is not only highly regulated as a health care company, but it’s also ISO 9000 certified, which means it has to have clear and concise policies and procedures for everything it does, including software development. “Our developers always feel like they’re running into someone telling them to stop,” said Meyer.

To fix this issue, Meyer said the team, “Completely change our perspective of how we look at our development processes and how those relate to our ISO processes. Things start working more hand in hand. I go do a black box test as soon as that’s done, maybe that kicks something off automatically to make an artifact to get signed off on, then it kicks back to the software development process, and on, and on.”

Meyer said many teams see continuous integration (CI) and continuous deployment (CD) as separate processes. After building and testing on the CI side of the fence, many developers simply throw the code over to CD and are then cut off from the remainder of the process.

“A lot of times, the only communications between development and operations is through JIRA requests and tickets: they punt their end state over the wall and we go into CD,” said Meyer.

To help bridge this gap between development and operations, said Meyer, the team adopted Concourse. “Concourse is a tool that pipelines the software development, CI, and CD all the way from coding, to taking it out, to getting into production. There are other tools like that, like Jenkins Pipelines. Concourse is very ephemeral in how it does things. A build job spins up a VM, does its thing, then tosses it away. If you’ve ever had to manage Jenkins boxes, you spend 20 to 30 percent of your time tending Jenkins boxes. That all goes away with Concourse,” said Meyer.

“These pipelines are declarative and written in YAML. Concourse has resources, jobs, and tasks. Resources are source code repositories, or end states and where they go: Artifactory, or something like Cloud Foundry or an instance could be a resource. Jobs act on those resources, and tasks are implementation details inside a job,” said Meyer describing the inner workings of Concourse.

“Concourse is extremely efficient at automatically moving code through a complete system like that. You can do 10’s or hundreds of deployments like this,” said Meyer. “We have five environments we move things through. One of the cool things Concourse has is a grouping mechanism inside the YAML. Using groups we can logically split out the pieces of the pipeline. Now you can ID where all the pieces of the pipeline are.”

Meyer said that regulations and governance severely restrict how often Cerner can push changes to production. “We’re forced into doing a cumulative cadence approach. We could only release into production at intervals. We have to give notification in our process two weeks before we move anything in there. Having a cadence is the antithesis of doing CI/CD, but for now, it is what it is.”

“We are doing a new solution already on Amazon Web Services and Pivotal Cloud Foundry (PCF), now we don’t have to worry about cadenced approaches. We can get more liquidity with microservices. Our process gets a lot more streamlined. We start with a version, we build it and test it. After it’s been deployed to the backend, if that’s good we move to QA, build it, and ship to production,” said Meyer.

“You want these things to become by-products of each other. The cool thing you can do inside Concourse is that all these ISO processes can become another resource. It doesn’t change the pipeline at all. When we move through our integration testing, we can fire off something in JIRA or Confluence that can send an email to the appropriate person. When they sign off, we have a Webhook that gets picked up in the pipeline and moves it to QA. After that, it fires another artifact that someone has to sign off on,” said Meyer.

Feature image via Pixabay.