SageSure Insurance Enables Continuous Feature Delivery with Postman
![Avatar](https://secure.gravatar.com/avatar/a306d92919e0c901b5075f9104bfaa05?s=96&d=https%3A%2F%2Fblog.postman.com%2Fwp-content%2Fuploads%2F2021%2F11%2Favatars-05.png&r=g)
This is a guest post written by Philip Myers, senior software developer at SageSure.
SageSure offers dependable homeowners insurance in catastrophe-prone areas where it’s needed most. We are an innovative insurance company that promises stability, peace of mind, and a commitment to being there for the long haul.
SageSure partners with many highly rated insurance carriers to serve the various needs of our markets. But what makes us stand out is that SageSure actually designs, develops, and files our proprietary homeowners and commercial insurance products ourselves.
Our approach combines the benefits that the carrier, underwriter, and distribution partners bring into one solid effort—and the result is unwavering, long-term support that agents, homeowners, and business owners can depend on.
The SageSure software team and Postman
The SageSure software team is focused on improving our development and delivery process. One high-priority process is continuous delivery of new features. This means no service downtime during deployment, and frequent small pushes to the production environment with a high level of confidence. This end-to-end deployment effort is realized with the help of many tools, including the Postman Collection Runner for test validation.
SageSure’s tech stack including the Postman API Platform has resulted in these key benefits:
- Approval of merge requests to production in under 60 minutes
- Increased frequency of smaller deployments
- A high degree of confidence with regression functionality
- Enhanced reliability of services at the micro level
Common deployment concerns
The questions our team assessed while looking to improve our process include: How do you get the code that is adding a feature or fixing a bug into a live environment? What team members are involved in the push? At what time does the push take place? Do you have a high degree of confidence that this new feature/fix will not break any current functionality? Does deploying cause any downtime for the user?
Companies have varying answers to these questions. As one example, some companies do quarterly deployments. But this typically leads to mountains of code for that release date and may mean that some projects are shipped incomplete because they needed to meet the deploy window but weren’t actually ready to ship. Here, some bugs get resolved, but other bugs are created due to the massive volume of code shipped and all the moving parts involved. Then, if a bug isn’t deemed important enough for a hotfix of some sort, that bug has to wait for the next quarterly deployment. This process often means more pains to address—pains for team as well as for the user.
While we never had quarterly deployments, we were working with a cumbersome deployment process. As part of our ethos of customer-centricity, continuous improvement, and the assessment I mentioned above, we arrived at the following approach.
The SageSure solution
Once a code change is approved through a merge request, many different test suites are run and, when they pass, the code is pushed to production without any service downtime. Deployments happen frequently—as often as code is merged; it’s not unusual to have three or more production deployments per hour. These deployments could be in different areas of our software: a UI enhancement here, a backend integration there, a bug squashed over there.
Testing, testing, testing
The beauty of frequent small deployments is that each package is validated through each level of testing. We have automated unit tests, automated helm tests, automated UI tests, and automated Postman tests. Each suite verifies the new functionality and also verifies no previous functionality has been altered or removed unintentionally. Pushing with confidence!
Each test suite is designed to test specific aspects of our software product. Unit tests confirm the behavior of the smallest testable parts of our code. Helm tests verify the server spun up correctly. Postman tests verify API functionality, both internally and with external partners. UI tests verify E2E paths are on their best behavior. The test after the server has launched is not yet accessible by live users; it is spun up in preview mode. Only after each test suite passes, is the new server then given traffic and the old server is spun down and no longer given live users.
The Postman test suite
This specific test suite attacks a unique problem: external and internal dependencies. With a validation suite collection in Postman, we can verify services are connected to an application in each environment as the pipeline progresses: database connection, internal DNS address routing, authentication, security, application to application connectivity, and third-party integration verification—to name a few. These tests are vital to ensure the application is up and able to communicate with other internal and external dependencies required to perform accurately. These tests are also designed to swap out environmental conditions and values. In a lower environment, we can verify connectivity to a test third-party endpoint, while the upper environment will verify the corresponding endpoint.
Going forward
SageSure has eliminated a tremendous amount of manual, repetitious work by investing in an advanced deployment pipeline. In doing so we’ve also managed to deliver with greater confidence for ourselves and in the experience of the user: no down time, and less bugs.
If a bug does get through, our process is to write a test that fails in the area where the bug exists. Is it a backend issue? Write a Unit test. Is it an E2E mismatch? Write an automated UI test. After the test suite has been updated to look for this case, we fix the bug and run the pipeline. Now, because of our investment in the test suites, we can be sure that:
- We fixed the issue.
- We did not introduce a different bug.
- This bug will not happen again in the future.
With this approach, we’ve been able to apply fixes to production issues in less than 60 minutes after they were discovered.
In short, this continual investment in our pipeline validation gives us more confidence with each iteration—more confidence, and a better experience for our users.
Delivering with confidence
Continuous delivery requires great confidence. Once achieved, it improves the quality of life for members of our development team. More regular working hours. Less stress on deployments. Less red tape. More backyard BBQs and weekend water park adventures. Getting here was more than worth it, and we have our excellent team to thank—as well as Postman.
Looking to work with the SageSure team? Find information on open positions here.
This article has also been published here.
What do you think about this topic? Tell us in a comment below.