1

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:

  1. I push a change to the API
  2. The tests are run to make sure that the API is green.

  3. Temporarily deploy the API and test the following wrapper libs:

    a. myapi-phpwrapper lib -- it has a test written in PHPUnit.

    b. myapi-ruby wrapper -- with a test written in RSpec.

4. If all of the above pass, then deploy the API. Otherwise, rollback.

  1. 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?

Improve this question
3
  • If you program to an interface. And that interface doesn't change. then there is no problem. If you however code to a class. Well, test, test and fingers-crossed – Pinoniq Jan 8 '15 at 9:40
  • @Pinoniq -- you might not break the compiler but downstream clients probably depend on behavior which you probably do want regression testing on. – Wyatt Barnett Jan 8 '15 at 13:47
  • Let me comment that major revision numbers (e.g. 1.0 to 2.0) exist precisely for that reason: some changes do break client code. I realize this is not solving your current problem, but I just want to remind you that such changes exist. – logc Jan 8 '15 at 19:15
1

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?"

Improve this answer
2
  • Thanks, fully agree on the deploy to production bit. Can you give us some insight into how you were able to get this setup done (e.g. tools, services, etc.) – FloatingRock Jan 9 '15 at 3:53
  • @FloatingRock -- I just expanded the answer to touch on that. – Wyatt Barnett Jan 9 '15 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.