Key concepts​​

In order to best understand the development environment best practices, it's important to review the Product modules overview guide. Below is a quick summary diagram.

Best practices in the development environment

There are essentially two major phases of the product module lifecycle: Pre-launch (not selling live policies) and post-launch (selling live policies). Regardless of phase, no testing should ever take place in the production environment – always opt for sandbox. Let’s examine best practices for both more closely.

👍

Rule of thumb

Rapidly develop and test in the sandbox environment. Mitigate being blocked by a deployment using the draft version functionality.

Pre-launch

While a product is being developed and no policies are being issued (i.e. no policies in the production environment) the developer can use the live and draft version to separate functional pieces of the build from work in progress.

As an example, after the policy issue flow has been built, it can be deployed for stakeholders to test on the major version of the product. Developers can continue to work on the draft version in parallel to build new features for the product, deploying to a new major version each time a new piece of functionality is done. The principle is that the live version of the product module should always be the latest bug-free, functional version of the product. From a Git point of view, your main and live (latest deployed version) should always be the same. More on this in the Git section.

The advantage of separating draft and live in the pre-launch phase is that you can control what stakeholders test and, importantly, demo to other stakeholders. In parallel, the developers can continue to rapidly build and test in a draft version. Ideally, you'd only introduce the draft testing functionality in the post-launch phase to stakeholders. In pre-launch, draft is used to rapidly build and test features. If stakeholders test on draft, they could potentially test features that are not ready yet.

Post-launch

At some point, the product will be ready to launch and will enter the post-launch phase. This is the moment when the first live policy is sold on the product. From this point forward, it is incredibly important that features being deployed into live are 100% functional, because it will influence real policyholders. The assumption is that after a product goes live, all features on the specification template have been built.

After launching the product, it’s very likely that new features will be added to the product. The development environment best practices will stay largely the same except for one difference: stakeholders will now have to test new features in a draft version in order to not affect live policies. Therefore, the features need to be built until completion, after which stakeholders can be notified to test. Once sign-off has been received, the feature can be deployed into live, and policies can be bumped to the latest version of the product.