In this article, I will be taking a look at the Whats, the Whys, and the Hows of Path to Live (PTL) – a path from development to deployment to production.
Path to Continuous Delivery (CD) can be long and scary 😥 Having a well thought and well-defined “path to live” helps make a long and scary journey to CD a lot smoother and can help you improve your deployment pipeline!
What is the Path to Live?
PTL is a pipeline that helps teams ship quality code with confidence and reduces frictions 🚢 PTL provides visibility, transparency, and a shared understanding of how development code will be delivered to the production.
So depending on the nature of the project PTL, it should be made part of the overall quality strategy.
Why Path to Live is important?
PTL is important because it:
- Highlights and visualizes what is needed to enable deployments to production.
- Creates a shared understanding among all team members of how to go about taking code from development to production.
- Defines quality gates and outlines testing activities involved at each stage.
- Provides a single source of truth to stakeholders, especially to engineers.
- Clarifies the purpose of each environment.
How to define a Path to Live?
By asking the following (but not limited to) questions:
- What are all the integration points/boundaries?
- Do we have the required and right number environment?
- What are the minimum testing requirements at each stage?
- What is the purpose of each environment?
- Who should be involved at different stages of the project?
- What is the measure that will qualify or promote code from one stage to the next?
Example Path to Live for a typical project
I’ve used draw.io to create this example. You can download the editable Path-to-Live file here to use, modify or share as needed.
Thanks for reading! 🎊 Hope you found it useful. Please don’t hesitate to share, or post your thoughts in the comments section. If you have any further questions or thoughts, please reach out to me on LinkedIn 🙏