IMO is a healthcare data enablement company. It provides accurate documentation, precise population cohorting, optimized reimbursements, robust analytics, and better care decisions to improve patient outcomes. In particular, IMO connects patient records with healthcare codes to make them easier to understand. IMO’s footprint of Electronic Health Records (EHRs) represents 89% of US clinicians, with more than 740,000 physicians using IMO at the point of care every day.
The GHO deployments were manual. Developers built the artifacts and handed them over to GHO to push out, which still involved manually copying files. Eventually, GHO started writing tools to verify the files were copied to the correct directory.
As GHO was also responsible for outages, there was confusion about who owned what with the development teams because it wasn’t their responsibility to keep systems running. In addition, there were no clear standards when building servers which were previously all hosted in Rackspace and handcrafted. A server in one environment could have one patch installed, while a server in another environment could be 3 versions behind.
In response to the risks in their deployment process, IMO started to modernize its CI/CD pipeline in 2013. The team began by implementing Git, then TFS. In 2015, with their needs still unmet, IMO decided to implement Octopus Deploy. Octopus fulfilled their criteria and solved numerous issues they were facing. Today, IMO is leveraging Octopus by:
- Standardizing their CI/CD pipeline and deployment automation approach.
- Using everything ‘as code’, with plans to adopt built-in support for Config as Code.
- Using the Octopus API, projects, and scheduled triggers to run tasks that audit Octopus Deploy.
- Integrating with the Octopus API to automate tasks and customize their experience.
- For example, they write custom API scripts for their help desk staff to save time.
- Running Terraform on Octopus.
As a result of leveraging Octopus as part of their CI/CD pipeline, IMO was able to solve multiple issues, adding consistency, automation and increased deployment frequency.
Octopus introduced consistency to IMO’s server configuration. Although IMO expected some variation between environments, they were pleasantly surprised by Octopus’s functionality. With everything now hosted in AWS, IMO leverages Octopus and Terraform to spin up new servers and auto scaling groups (ASGs).
Octopus has a trigger that monitors when a new server is added, installing the software for that server to function.
It also means there is a standard way and specific settings to deploy a web service to IIS, making deploying applications consistent.
Octopus also introduced consistency with deploying anything, anywhere. IMO started using Octopus to deploy software to their build servers and help desk staff.
Leveraged automation step templates
Octopus enabled IMO to standardize across projects and teams, through the steps Octopus provides for normal standards, and by extending Octopus to enforce additional custom standards.
Enabled DevOps practices
When they first implemented Octopus, GHO was responsible for ‘pushing the button’ to production and managing the production variables. Meanwhile the development team was responsible for building and managing the deployment process. With Octopus, they shifted the responsibility for production from GHO to the development team, who have grown to 18 DevOps teams in their their software engineering department. These DevOps teams are now responsible for deploying to production, managing and monitoring their software, and getting notified when outages occur.
Enabled DevOps practices
Before Octopus, IMO deployed to production infrequently, usually once per quarter. Now, IMO deploy once per week to several times per day.
This has been especially beneficial during the pandemic. As doctors learn more about COVID-19, the healthcare codes need updating. These codes are stored in massive data files that need to be deployed to a variety of servers quickly. Without Octopus, IMO staff would have to work late nights to cover the required deployments. However with Octopus, they deploy smaller chunks more frequently, with deployments measured in minutes, not hours.
Octopus has also reduced manual verifications. IMO now has a robust PR (pull request) process to verify a branch before merging to main. All branches are deployed to a pre- production channel to validate the code changes. After a change is merged to main and built by their CI server, they push to the default channel in Octopus. Octopus then uses automatic deployments to push the changes to production.
We've been overhauling our internal infrastructure and back-end systems over the past month, including a move back to full @OctopusDeploy deployments; rediscovering how nice it is to have a platform-agnostic orchestrator that can deploy practically anything, anywhere ❤Nicholas Blumhardt