LinkedIn
Twitter
1 ACCEPTED SOLUTION
Good point Nagashree. You're deepening your knowledge into how to structure your code in Git either leveraging multiple branches or repos per API. So here are some recommendations to define your branching strategy and job definitions in Jenkins:
1) Release each API as an independent shippable component/microservice. In order to achieve this, you'll need to either have each in a separate repo (API-centric with multiple repos) or have a separate master/develop/toggle or feature branches per API. The former is approach is recommended, since there's lower risk of colliding with branches from other APIs. Also, it specializes your teams per API and given the low cost of Git repos.
2) Define jobs in Jenkins: Once you defile your version control strategy, define jobs per API per environment. The ultimate goal is to have a job per API, instead of one job for all them. It'll again will run regression tests for each API as well as any consumer-driven contracts independently from other APIs.
3) Define events that trigger Jenkins jobs: Each job can configured to be triggered by either commit (merge or pull request) checkins or on a schedule basis.For example, the checkbox below will trigger the job every 15 minutes, if there was no new code checked in, the job will not be executed, so it won't redeploy the API. Only, when it finds new code, it will kick off the job from end to end, so apigee maven deploy plugin will be executed and the API verified, deployed and tested.
