As a working demo of microservices in action, Spring Trader lends itself very well to showing continuous delivery and zero-downtime deployments. Individual services can easily be tested and updated while the application as a whole continues to operate.
Jenkins is the most popular field tool for CI/CD demos, but the project as currently organized doesn't work well with Jenkins. Jenkins can generate generic "something in this Github repo has changed" events, and trigger a build off of that. But the Github plugin for Jenkins will not work at the granularity of identifying which files have changed, in order to determine which services need to be deployed.
So for field demos, we have had to clone the project, and set up a "one-repo-per-microservice" structure in order to create a Jenkins demo that can build and deploy the correct service on code change.
Does it make sense to reorganize this project in that way, or is there a suggested alternative method for doing CI/CD demos?
As a working demo of microservices in action, Spring Trader lends itself very well to showing continuous delivery and zero-downtime deployments. Individual services can easily be tested and updated while the application as a whole continues to operate.
Jenkins is the most popular field tool for CI/CD demos, but the project as currently organized doesn't work well with Jenkins. Jenkins can generate generic "something in this Github repo has changed" events, and trigger a build off of that. But the Github plugin for Jenkins will not work at the granularity of identifying which files have changed, in order to determine which services need to be deployed.
So for field demos, we have had to clone the project, and set up a "one-repo-per-microservice" structure in order to create a Jenkins demo that can build and deploy the correct service on code change.
Does it make sense to reorganize this project in that way, or is there a suggested alternative method for doing CI/CD demos?