How We Make Trello

Post by girvo » Fri, Mar 14, 2014, 12:57 AM UTC

dpatti wrote: post #63

jamessocol wrote: post #26

I'd love to hear—maybe I missed another blog post—why they went with the single release manager, where only one person can merge and deploy. What happens if Doug is sick or on vacation? Or even just in a meeting? What is a typical amount of time for a change to sit in "ready for merge" or merged but not deployed?

The primary benefit is that it creates a single point of communication for the developers, the designers, and the QA. It also helps with prioritizing changes that could be conflicting and, in the same vein, helps prevent bad releases or merges. And, of course, anyone can do this job. If I'm not available, someone picks up the slack. I just volunteered because I was interested and available. All that said, I think tha…

Post by nevster » Fri, Mar 14, 2014, 2:33 AM UTC

Post by rmccue » Fri, Mar 14, 2014, 5:45 AM UTC

bib971 wrote: post #92

bobbygrace wrote: post #20

Earlier quoted context omitted.

I hope Doug writes a more technical post about the multi-client build/release process. We have unit tests for the whole API and very few automated tests for the front-end. Client builds are stored in S3. We use mongoDB and will do backfills if necessary (pretty rare). Rolling back the client is just pointing the stable branch to another build.

Bobby, you said every app is a client of the API. I notice Trello.com consumes API from https://trello.com/1/xx while an OAuth client (from one of your Jsfiddle examples) consumes from https://api.trello.com/1/xx?key=xx&token=xx . I suppose the former just passes through to the later? If so, does the former needs to pass over the key and token (I suppose you can generate on the fly based on auth cookie)? I'm trying t…

Post by porker » Fri, Mar 14, 2014, 8:26 AM UTC

copergi wrote: post #77

thedufer wrote: post #62

Earlier quoted context omitted.

Not completely orthogonal. The way Trello is set up, client and server releases are completely unrelated and don't have to know about each other. The web app is almost as separate from the server as the iOS/Android apps, which isn't really possible if you're rendering html in the server. That said, I agree that making something into a single page app just to get this separation isn't going to be useful.

>which isn't really possible if you're rendering html in the server. Yes it is, that's my point. Our designers push new templates and our developers push new binaries completely independently. We literally have an API doc that the designers put "I want this" into, and the developers implement it and update the doc to reflect it being finished. People just use template systems that make this unnatural. See heist for a…

Post by 13hours » Fri, Mar 14, 2014, 9:10 AM UTC

upops wrote: post #25

sidcool wrote: post #14

So they create a new branch for each fix? And all developers are supposed to merge in their branch every few hours or so? Isn't it a bit of a drag?

On the Trello Android team we have a similar workflow to the web client and server developers. We merge in to a shared development branch when we have a complete feature or bugfix. With git's --no-ff this allows us to see when a new feature was implemented, and when bugs pop up we have a clear list of intersections where they could have been introduced. Our workflow is roughly based on an excellent post by Vincent Dr…