Search code examples
jenkinsmicroservicesjenkins-pipelinecontinuous-delivery

How to manage continuous delivery with micro services?


Right now we are working with Jenkins as our CI and CD, we are also using an Agile methodology (sprint). I was wondering how can I manage the releases of my software.

For example we are developing a shopping site for a business. The development consists of an application which consumes 3 micro services.

Components:

Application: Is the user interface
Micro service 1: Sales
Micro service 2: Users
Micro service 3: Products

Initial state of the shopping site:

We start developing the shopping site from scratch. As I said before we are working with an Agile Methodology (Sprints).

Sprint 1:
- Develop products micro service.
- Develop users micro service.
End of Sprint 1

By this time I can only apply micro service testing, like unit testing, contract testing, etc. Because I don't have the application ready I can't make end to end testing or functional testing based on the entire system, as well I can't deploy to UAT environment (show a beta version to the users) because the user wont be able to do exploratory testing. So for now I need to wait until the application and sales micro service is finished, so I can show the beta version to the user and apply any other type of testing.

Sprint 2:
- Develop sales micro service.
- Develop application.
End of Sprint 2

Now that all the components needed are finished to accomplish the user requirements, we can continue with the pipeline. applying all the testing needed before we show a beta version to the user.

So the million dollar question is, how would you do this scenario with Jenkins and GitLab?

I understand that micro services should be independent to every component in the system, but at the end the entire system depends on each other, for example if I add a new micro service like "shipping", this new functionality should be seen in the application interface, so it means that before releasing the new system I have a dependency on "shipping" micro service and the application interface, because without both developments I cant fully test the user requirements before deploying to production.

P.S. I'm sorry for any confusion in this post, but I complety new at this topic.


Solution

  • The "independent" aspect of microservices is essential here. Basically, you should be able to treat each service as a standalone app, and your UI should not depend on sales/users/products services as "libs" (e.g. C# DLL, Java Jars, etc.) but should instead use some kind of API (e.g. REST API) to call each other.

    To illustrate the difference, you should not have this :

    enter image description here

    But instead you should have something like this.

    enter image description here

    Now let's assume you are in the wonderful microservices world with REST API between your UI and each of your services.

    In Jenkins, it becomes rather simple. For each service (+ main app) you want a job that compiles, tests, and deploys your service on the target server.

    enter image description here

    As long as your services are independent and if you handle app versionning correctly, you shouldn't need any kind of synchronization between any of your Jenkins jobs.

    Of course the build/test/deploy process would be externalized in a common pipeline file so you can reuse it across your different jobs. Just commit a new API endpoint on the sales service before you commit the UI part that uses the new sales endpoint... but I think that just common sense !

    If you're new to Jenkins a good start is the pipeline documentation !