LinkedIn
Twitter
Firstly: What this article is NOT about!!
Talking about why you should do CI/CD. There are lots of great materials about that on the internet, If you care you can find them!!
Talking about branching strategy. We would like to fit in with your SCM and branching strategy without dictating what yours should be.
Low level details about how exactly a specific strategy will work or how to use a specific tool to achieve CI/CD.
I have worked with many customers in the past year or so on their CI/CD strategy and their implementation for the same. What I realized more than anything was there was no one single pattern for implementing Apigee CI/CD. That is a little troubling. We agree 100% that there can never be one size that fits all, but there definitely are some best practices and few patterns which works better than other.
We deeply care about SDLC and CI/CD and have many many many internal debates about. In this article I have tried to capture various CI/CD patterns which we think makes the most sense. This is a very high level discussion and we hope customers can start from this doc to think through how best to do CI/CD with Apigee.
There are some people who are more passionate about one pattern over other. Hence in this article I have tried to keep all emotions aside and present pros and cons of different patterns, so that customers can choose which pattern best suits them.
Scenario 1: Development using Apigee Proxy Editor:
This is the most common and most intuitive model. This is where the journey of every customer starts. In this pattern, customers do all the development using the UI. Then the artifacts are exported and saved into SCM. Once in SCM, then a CI/CD software like Jenkins is going to pick it up, bundle it and deploy it to all higher environments.
- Easy to use UI
- Drag and Drop policies
- Integrated external documentation
- Useful for advanced use cases like Oauth, proxy chaining, Shared Flows, Flow hooks etc.
- Integrated debugging capability using Trace
Cons:
- If multiple people are working on the same proxy then there is no easy way to do conflict resolution.
- There is no easy way to push the policies/proxies to SCM.
- There is no easy way to do change management, reviews, bug fixes etc.
Useful for:
- Smaller API teams- Especially if not many people work on the same proxy at the same time.
- Apigee is used part time, so no one has has full time responsibility of Apigee hence do not possess deep understanding of the platform.
- API programs are small.
- Customers who do not have a formal/stringent CI/CD pipeline.
Scenario 2: Local Development
Pros:
- Multiple people can do the development at the same time.
- You can keep using your favourite editor - Eclipse, Atom,sublime etc.
- Existing toolsets for code review, code coverage etc. can be leveraged.
- All configurations outside proxy like KVM, cache, certificates, Target servers can be exported and saved in the SCM in an uniform way.
Cons:
- You have to be familiar with Edge XMLs.
- Apigee does not officially publish the XSDs, so no way to validate the XMLs offline.
- There is no drag and drop UI. You can build everything using any XML editor of choice.
- Traditional, less agile approach. May be overkill for smaller teams.
- Complex for building advanced use cases leveraging Proxy chaining, Shared flows etc.
Useful for:
- Large distributed teams
- Larger API programs
- Apigee is deeply integrated in SDLC
- Customer have formal/strictly enforced SDLC
Scenario 3: Local or UI Development and presubmit testing
In this scenario, a developer develops code, runs test cases and if it passes only then checks it into SCM.
Let’s say a developer (Sam) is working on /foo API. That API is worked on by 2 other developers (John and Woo). When Sam develops the API he checks it out and creates a new proxy with basepath /sam/foo. Similarly John and Woo also creates two proxies like /john/foo and /woo/foo. Thus each can work on their own build separately and when deploy on Edge to run all test cases. Once the test cases are passed only then they are submitted to SCM.
The development can be done using either of the previous methods: using UI or locally.
Pros and cons are very similar to previous two scenarios. The obvious benefit is code is tested before it is checked into SCM. But it adds additional complexity of having many different proxies. If there are 4 developers and each is working on 5 proxies then there can be 20 different proxies in dev environment which can cause some confusion. Especially if the number of developer or proxies are higher.
Hybrid development (Because, why Not!! Hybrid is the buzz word, afterall)
Some people argue that an ideal model is a best of both worlds:
Do any new feature development using the UI. Examples: Building a new SOAP-> REST transformation, OAuth etc.
Do any modification/incremental changes to proxies/policies using offline XML editors. Eg. Change configurations for cache, implement a spike arrest policy etc.
I have seen a few other patterns in the wild:
- Use Apigee UI completely to manage propagation between different environments
- No SCM integration: Development in UI and have a Jenkins/Bamboo Job export the bundle and deploy it to higher environment.
- Using artifact repository managers like JFrog
- Proxy development integrated with SCM but not other configurations like KVM,cache, Target Servers etc.
We are not huge fan of these patterns though.
CI/CD tools:
Irrespective of which of the above scenarios you want to follow, following few tools you should be familiar with:
Maven plugin:https://github.com/apigee/apigee-deploy-maven-plugin
This is the primary tool using which you can build the automation
This tool will take care of deploying/undeploying/deleting the proxies and many other related tasks.
Maven config tools: https://github.com/apigee/apigee-config-maven-plugin
This tool is needed to do a bunch of additional tasks like creating caches/KVMs etc. Most likely you will be using these two tools in Tandem.
There are few other tools:
This is a good command line tool to interact with Edge:
Apigee grunt plugin:https://github.com/apigeecs/apigee-deploy-grunt-plugin
Apigee node tool:https://github.com/apigee/apigeetool-node
This is especially useful if you are trying to deploy node apps in Apigee. This is an easy command line tool to deploy node.js apps and proxies on Apigee.
Management APIs: All these tools are wrappers around management APIs. So we would strongly recommend you to be familiar with the management APIs, which you can see here: http://docs.apigee.com/api-services/content/api-reference-getting-started
A few other great resources on this topic:
https://community.apigee.com/articles/34868/source-control-for-api-proxy-development.html
https://community.apigee.com/articles/35173/continuous-integration-for-api-proxies.html
https://community.apigee.com/articles/16169/forming-an-api-test-strategy-where-to-start.html
https://community.apigee.com/articles/2685/apickli-rest-api-integration-testing-framework-bas.html
