Maybe you are wondering, "why is there an automation recipe in a Java EE 8 book?", or even, "is there any specification under Java EE 8 that defines a pipeline automation?"

The answer to the second question is no. At least no at this very moment. The answer to the first one I'll explain here.

Many times in conferences I am asked the question, "how do I migrate my monolith to microservices?" It comes in some variations, but at the end of the day the question is the same.

People want to do it for different reasons:

• They want to keep up with the trend
• They want to work with something that looks like a new fashion
• They want to scale an application
• They want to be able to use different stacks under the same solution
• They want to look cool

Any of these reasons are OK and you can justify your migration to microservices with any of them, if you want. I would question the real motivation of some of them, but...

Instead of giving them advice, tips, guidelines, or any other tech talk, I usually ask a simple question: "Do you already have an automated pipeline for your monolith?"

Most of the time, the answer is a disappointed "no", followed by a curious, "why?".

Well the answer is simple: if you don't automate the pipeline you, monolith, one single package, and sometimes you have problems with it, then what makes you think that it will be easier when you have dozens, hundreds, or even thousands of deployment files?

Let me be more specific:

• Do you build your deployment artifact manually? Using an IDE or something?
• Do you deploy it manually?
• Did you ever have problems with the deployment for any reason such as errors, missing artifacts, or anything else?
• Did you ever have problems due to the lack of tests?

If you answered yes to at least one of these questions and don't have an automated pipeline, imagine these problems multiplied by... again, dozens, hundreds, or thousands.

Some people don't even write unit tests. Imagine those hidden errors going to production in a countless amount of artifacts called microservices. Your microservices project will probably fail even before going live.

So yes, you need to automate as many things as possible in your pipeline before even thinking of microservices. This is the only way to prevent the problems from spreading out.

There are three maturity stages for an automation pipeline:

1. Continuous integration (CI): Basically, this ensures that your new code will be merged into the main branch (for example, the master branch) as soon as possible. It is based on the fact that the less code you merge, the fewer errors you add to it. It is reached mostly by running unit tests during build time.
2. Continuous delivery: This is one step further from CI, where you guarantee your artifact will be ready to be deployed just by a click of a button. This usually requires an artifact repository for your binaries and a tool to manage it. When using continuous delivery, you decide when you will do the deployment, but the best practice is to do it as soon as possible to avoid adding a lot of new code in production in just one shot.
3. Continuous deployment (CD): This is the last, state-of-the-art part of automation. In CD, there's no human interaction since the code is committed until it is deployed in production. The only thing that would prevent an artifact from being deployed is an error in any of the pipeline stages. All the major success cases of microservices worldwide use CD in their projects, doing hundreds or even thousands of deployments daily.

This recipe will show you how you can go from zero (no automation at all) to three (CD) in any Java EE project. It's little a conceptual recipe, but with also some code.

Don't argue against concepts; they are the key to your career as a Java EE developer.

"Going microservices" is a huge thing and means lots of things both in your application and organization. Some people even say that microservices are all about scaling people, and not technology.

Here we will, of course, keep on the tech side of things.