When you use containers for your application, one of the things you need to think about is how to move (aka promote) the container images you generate across different environments.
In this series, I will explore different ways to do so... with the help of Azure DevOps
Intro
In the first article of the series we explored the "Base Registry" approach to promote a Container image across different environments.
In the second part we got rid of the additional registry and we used a Build Artifact.
In the third and final part we have used the same approach as the second one, but using 100% the YAML Pipelines (or, more appropriately, the Multi-stage Pipelines).
In this bonus post you can find the link to the YouTube video where I explain this approach.
The video
I decided to create this video to explain the theory behind this approac, and also to show in practice how this is achieved with Azure DevOps.
Here you have it:
Conclusion
I hope you enjoyed the video, and if you did please like it and subscribe to my YouTube Channel, called CoderDave.
I'd appreciate if you could help me growing the channel sharing it to your friends, colleagues and contacts.
Thank you!
Top comments (2)
Do you have an article that explains how to make the base image compliant when an update is released?
No I don’t, sorry. Not yet at least 😉.
I guess one could monitor the base image registry and automatically build a new image when a base image is released, so to have control. Of course you could scan it using your own security toolkit and so on so forth