Imascap's Blueprint Server
Submitted By Jenkins User Christophe Carpentier
Many healthcare professionals turn to the Imascap Blueprint 3D Planning PSI system from Wright to access critical patient information. As demands for the services grew, so did Wright’s technology team, who required an agile DevOps environment that would grow and scale as the team did, so developers could focus on building great code rather than infrastructure.
Organization: Imascap/Wright | www.wright.com
Project Website: http://www.wright.com/blueprint-3d-planning-psi-system
Programming Language: Java, Node.js, PHP
Version Control System: GitLab
Build Tool: Maven
Community Support: Jenkins.io websites & blogs, and spoke with colleagues and peers
Powering an evolving blueprint 3D planning system for the medical industry.
Background: Wright Medical is a global specialty orthopedic medical device company providing extremity & biologic solutions. The Imascap development team supports Wright’s Blueprint 3D Planning PSI system, which is a management system for surgeons. As the number of healthcare professionals using this software increased, the technology team behind Imascap also needed to expand. The developer team grew from a three-person shop to eight, and the software team relying on the web solution would soon surpass 40 employees. It was clear that Wright Medical needed an agile DevOps environment that could scale alongside them.
Goals: Switch to an agile DevOps process that would allow for quick feedback and exponentially more testing to support a growing development team.
Solution & Results:
First, we made a transition from an aging PHP stack (4% coverage, no continuous integration) to a full-stack (Spring/Angular) solution. The release process mostly consisted of checking out the code and fixing it live on different platforms. We secured the existing stack, set up continuous integration, automated the unit tests, and set up a proper git workflow.
Then, as the new stack fleshed out and the team got bigger, we added one — then soon eight — java microservices. We automated the builds, set up docker integration, then provided our new developers with an “all-included” dev-kit. We then set up a test machine with this dev-kit, established daily delivery to this environment, and rolled it out to most of our environments. At the same time, we set up a SonarQube instance and integrated with GitLab for near-instant feedback on merge requests. Meanwhile, we increased code coverage to around 70% on our 250K+ lines of code.
What was critical to our success was the stability of Jenkins and a great number of reliable plugins! We could take a few plugins, set up our workflow, and add GitLab and SonarQube integration without ever stopping or losing data in over a year.
We found that all of the problems we encountered were our own, and that is why it was critical to make Jenkins an essential part of our workflow. With this implementation, Jenkins allows more than would be manually possible. It flawlessly updates our staging environments, blocks commits based on the SonarQube analysis and provides us with near-instant feedback on merge requests.
Now we are steadily working on proper continuous delivery and getting rid of the remaining parts of the old stack. Everything is looking good! Our results?
- daily releases on staging environment vs. weekly and manually
- improved quality and quick feedback
- SonarQube integration means our code is never getting dirtier
Like what you see? Share your Jenkins user story today