One of the greatest advantages of using docker containers is the fact that you can move them between environments. A promotion from Development to a Production environment, shouldn’t take more than some few seconds. This is one aspect of “Continuous Delivery”
Because Microservices Architectures are “independently replaceable and upgradeable”, they are the best scenario to show a “Deployment Pipeline”.
Red Hat Developers has produced a sample and free application called “Red Hat Helloworlds MSA” that demonstrates different aspects of microservices (You can read more about this application in the following post: Have your own Microservices playground). This application shows how you can independently deploy the microservices using different technologies (JAX-RS and WildFly Swarm, Spring-boot, Vert.X, NodeJS, etc) and how you can use different invocation patterns to integrate them. It also uses Netflix OSS, integrated via Kubeflix, and ZipKin for tracing.
The sources of these microservices are available in the following repo: https://github.com/redhat-helloworld-msa/helloworld-msa. You can follow those steps and have your own “microservices playground”. There’s an amazing demo in a video recorded by Burr Sutter: https://www.youtube.com/watch?v=SPATMHP-xw8
But what happens if you “detect an error” in production? How can you be benefited by Openshift to replace this “error” in a transparent way for the microservices client (continuous deployment)? To answer this question, the following video shows how you can use Jenkins and the Pipeline plugin to trigger the build and promote deployments from the “Development” to “Production”. The most important part to me in this whole deployment process is the fact that the application is always available. Enjoy de video and don’t forget to try it yourself!
http://www.youtube.com/watch?v=N8R3-eNVoEc
Last updated: March 16, 2023