1 minute read

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”.

In the last two months, I’ve been working on a Sample application called “Red Hat Helloworlds MSA” that demonstrates different aspects of microservices. This application show how you can indendently deploy the microservices using different technologies (JAX-RS (EAP and WildFly Swarm), Spring-boot, Vert.X, Dropwizard, NodeJS, etc) and how you can use different architectural patterns to integrate them. It also uses Netflix OSS, integrated via Kubeflix, and ZipKin for tracing.

The source 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? To answer this question, I recorded a demo that 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!

Updated:

Leave a comment