Time for Change: How to approach an OS project switchover*
So, who here has an open source project they maintain? Ok, of those people, who calls out or references. Who's had the other thing change in a certain way causing bugs and general headaches?
It's a pretty common problem in open source, especially when you're dealing with API's and such.
Eventually, services change, move, change, or even shut down completely. And it becomes a tricky decision on how to deal with this change, and how to switch over from an old service to the new.
I'm going to talk about how you approach sun-setting interfacing with an old version of a service, and switching over to the new version, cleanly, with lots of spec coverage and testing.
I'm not going to pretend that. We're not even fully finished with the switchover yet, and there's still plenty more to learn. But hopefully you won't make the same mistakes we did.
When you maintain an open source project that depends on an API, you begin to get very comfortable with it. What works, what doesn’t work, it’s quirks. You talk to other people working with it, you talk to the people actually working on it.
But, time moves on and sometimes you need a change. Then comes along the shiny new API 2.0! Oooooh, more stable, more endpoints, OAUTH for authentication, it’s all very snazzy.
So at what point do you sunset the old and bring in the new? How do you even do that?
I’m going to talk about how to approach a big change on an open-source project, how to approach it, how to test it, and whether it’s even a worth-while change to make.
I’ll talk about how we made the big change on the command-line tool “Tugboat” which talks to DigitalOcean and the progress of switching over to it’s new v2.0 API, what decisions we made, what worked and what didn’t.
There’ll be a particular focus on Ruby and DigitalOcean’s API, but a lot of the concepts can be applied to a project that has a big change on the horizon. Hopefully you won’t make the same mistakes we did!
api, oss, Open Source, digital ocean
Talked before at smaller meetups, but given several lighting talks at larger events like PuppetConf and Config Management Camp
One recorded event: https://skillsmatter.com/skillscasts/5496-testing-servers-like-software