GoodRx, a digital healthcare platform, has released the Lifecycle project as open-source code. Lifecycle is a complete solution for temporary/ephemeral environments. The project’s build process includes built-in support for Codefresh pipelines.
Creating preview environments from a Pull Request with Lifecycle
Lifecycle was conceived as an internal project back in 2019, and today it is released to the world as a fully open-source project available at https://github.com/GoodRxOSS/lifecycle
The project covers two very popular scenarios for medium-sized developer teams.
- Creating a complete temporary environment with the contents of a pull request
- Creating some services with the contents of a pull request while still using several dependencies from a shared/staging environment
Lifecycle comes with its own abstraction for service definitions. You can see the full syntax in the documentation page.
This file (lifecycle.yaml) allows developers to define several microservices that take part in the application and their dependencies.
When a developer creates a Pull Request, Lifecycle understands all the dependencies and their changes and launches preview/ephemeral environments either for all services or only those selected by the developer.
Even though Lifecycle includes a simple Graphical User Interface, developers can use the Pull Request itself to see what is happening.
When a GitHub project is augmented with Lifecycle, a smart comment is added on each Pull request that shows the state of the preview environment. From the same comment, developers can enable or disable specific microservices and even redeploy the entire environment by clicking on checkboxes.
Once the Pull request is merged (or closed) the temporary environment shuts down on its own. You can see a full demo of the developer experience in a Youtube recording.
How Lifecycle works
Lifecycle itself is a self-hosted application available as a Helm chart. Currently, it supports Google Cloud and Amazon Web Services. You need to install Lifecycle in a Kubernetes cluster. If you are using Terraform/OpenTofu you can easily bootstrap everything required with an example Git repository.
Once you install the Lifecycle GitHub app your developers are ready!
There are many ways to define how environments are created. You can choose to auto-create an environment for each Pull request or require a specific label before a deployment happens.
Developers follow their usual workflow.
- First they create a feature locally
- Once ready, they commit and push to a Pull Request
- They can view their feature in isolation in an environment specific to a Pull request/branch
- They can choose to accept or discard a Pull request at any point in time.
Lifecycle essentially supercharges your Pull requests because, in addition to the usual checks (unit tests, code coverage, security scans), they now show a URL with the application running for live verification. Apart from developers, other teams (testers or database administrators) will find this functionality very useful for quick manual tests or other checks that require deploying the end result.
Why Lifecycle is different
Preview environments are a well-accepted practice in the software industry and several approaches exist for solving this problem. We have actually offered our own advice both for plain Helm applications as well as GitOps workflows with Argo CD.
What distinguishes Lifecycle from the competition is the “fallback” mechanism it offers. Sometimes creating a full replica of the whole application is either too costly or too complex. Especially for teams that have adopted microservices, the usual scenario is that changes exist only in a subset of the services while the rest are still on the latest version.
Lifecycle allows you to define a fallback/static environment that will take effect for services that the developer does not select. This means that the developer now has the full power to select only a subset of services to participate in the Pull request, while still using the latest stable version for everything else.
This static/shared environment is also handled from a specific Pull request again by Lifecycle. This means that developers can choose to examine new features in individual branches and when they feel confident they can move them to the shared static environment with a simple merge.
We have seen several tools that excel in one scenario (launching everything) or the other (keeping a shared testing environment), but Lifecycle is a unique tool that focuses equally on both use cases.
If you want to try Lifecycle get started at the official documentation.