0

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.

Pom12
  • 7,622
  • 5
  • 50
  • 69
Carlos Nasser
  • 153
  • 1
  • 9
  • I don't think you are using microservices, it seems strange that an "application" will depend on microservices. Also, it is unclear what your are asking, you should probably edit your question to be more specific about what exactly you want to do, name your jobs, tell us which job should run first, etc. – Pom12 Feb 17 '17 at 09:21
  • @Pom12 thanks for your response and sorry for the lack of detail, i just changed the description. I hope is better and i'll appreciate a lot your help, as you know i'm a bit lost in this topic. – Carlos Nasser Feb 17 '17 at 14:49

1 Answers1

0

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 !

Pom12
  • 7,622
  • 5
  • 50
  • 69
  • thanks a lot for your explanation. So to check if i understood, the decision of which component to commit first should done by a human, there's no way jenkins can manage this. – Carlos Nasser Feb 17 '17 at 15:34
  • Indeed. Jenkins is just a CI tool, it can automate a few actions (build /test /deploy) but in no way it should drive the way you code or architect your code. – Pom12 Feb 17 '17 at 16:26