Customer Case Study: iPipeline

iPipeline is a leading provider of cloud-based software solutions for the life insurance and financial services industries. The company provides a SaaS-delivered solution that helps end customers accelerate and simplify insurance sales, compliance, operations, and support. iPipeline is headquartered in the United States, and of its 841 worldwide employees, nearly 70% are focused on application development or IT operations management. The iPipeline DevOps teams, which are geographically dispersed in the United States and the United Kingdom, support customer-facing applications with over 600,000 registered users globally.

While iPipeline was using DevOps CI/CD automation processes, the company still released software in the evening using a waterfall approach, lacking the confidence to roll out new application features incrementally during the day. New feature releases came out monthly and were deployed to a pre-production environment where iPipeline integrated its new releases with other development partners' software updates. This pre-production environment enabled testing of the new release before rolling out the software into the actual production environment.

iPipeline developed software on long-lived source code feature branches descended from the master branch. The updated feature branch was not merged back into the master codeline until the work was completed. Since the master codeline is a single shared codeline, it receives ongoing updates from other feature merges, so the underlying code is often different from when the original feature branch was created. As a result, application developers had to manually alter the master codeline to address source code merge conflicts. This process not only was time consuming but also introduced the risk of undetected merge-related software bugs late in the application development process.

The iPipeline DevOps teams wanted to be able to release more frequently using a blue-green progressive delivery technique. This style of application release allows DevOps teams to gradually transfer user traffic from a previous version of the application to a new release while both versions are concurrently running in production. The older version of the application is considered the blue environment, and the latest version is known as the green environment. However, there was not only a lack of adequate tooling but also a fear that a problematic update could disrupt the production environment without the ability to roll back the change swiftly.