[edwinnathaniel]

I'm more interested to know the actual technical details of the build and testing process than the "Task-List" software development based approach because that can be done by any software project management tools (even JIRA).

What's missing in this article is the whole Continuous Delivery technical aspect of it.

What do you guys use to build the NodeJS app?

What do you guys use to test the NodeJS app?

What do you guys use to check the code coverage of the NodeJS app?

What do you guys use to test the front-end?

What is the automated testing strategy?

How do you store artifacts of builds, schema migration (if using RDBMS) or handle different model versions, how do you rollback (what's the rollback strategy)?

[bobbygrace]

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.

[bib971]

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 to get my head around the fact that your app provides OAuth for other clients and at the same time (from what you're saying) your app is also one of such clients. Not sure how it really works.

[rmccue]

If you control both the OAuth client and server (that is, the client is always trusted and doesn't need manual authorization), you can dispense with request tokens and just issue access tokens directly, and forget about the whole authorization flow.

[hamidpalo]

Trello dev here.

The web client (trello.com) has a cookie that has the auth information. The actual code executed for both examples is identical.

[thedufer]

api.trello.com is just a CNAME to trello.com, in case that difference was confusing you. The authentication part is taken care of differently depending on the kind of tokens we get (the web client uses a cookie) but we turn that data into a standard authentication object and the rest of the route uses the same code regardless of request type.

[bib971]

Got you. This is very helpful, thank you!

[edwinnathaniel]

Please ask Doug to write that ASAP :D (just kidding).

NodeJS community (and to some extend, the RDBMS/NoSQL crowd that wonder how to support different version of the model) would probably learn greatly from that type of article.

[bobbygrace]

er, by stable branch, i mean stable _channel_. or whatever channel.

[hessenwolf]

I've sent this to a couple of people around our multinational already. While I get what you are interested in, I have to commend them for this excellently written article. Would that our actuarial models were maintained with anything approximating this level of sophistication.

disclaimer: my entire life is run via trello.

[tel]

Is it actually NodeJS even?

[bobbygrace]

Yup. More about the tech stack here http://blog.fogcreek.com/the-trello-tech-stack/

[jt2190]

Yes. Check out the interview the Trello team did on the NodeUp podcast: http://blog.fogcreek.com/trello-server-team-on-nodeup-podcas...