I’m setting up the Continuous Integration process for our API and I’ve split my brain trying to figure out how to connect that process with the API wrapper libs too.
Here’s what I want to happen:
- I push a change to the API
- The tests are run to make sure that the API is green.
-
Temporarily deploy the API and test the following wrapper libs:
a.
myapi-phpwrapper lib — it has a test written inPHPUnit.b.
myapi-rubywrapper — with a test written inRSpec.
4. If all of the above pass, then deploy the API. Otherwise, rollback.
- If the above pass, then deploy to production. Otherwise, keep the previous version of the API.
That way, I can be sure that changes we push to the API don’t break our wrapper libs. I can’t be the first person to be doing this .. Ideas?
3
I’ve done similar things in the past. In general that plan works though you certainly want to fix the end to be “if tests work deploy to production and re run external tests” rather than rolling back if you have the infrastructure to support it.
You also might want to think about versioning the api up front as a prophylactic measure.
In terms of tools, there are a number of CI platforms out there of various sorts. The best of breed are TeamCity (free for small scale / relatively cheap for more ) and Jenkins (FOSS). There are some cloud deployment services but I have not used any of them so I can’t say what would work better. They tend to be tied to specific platforms and/or services so that will likely help you narrow the field.
The real work is in building your codebase to be 100% deployable by automated processes — to a large extent the CI servers are just a fancy reporting layer for that action. Exactly how to get there really depends on specifics about the API and codebase but the place to start is “Can I build and deploy this from the command line without human intervention?”
2