5 ms·

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

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

tel 13y ago
Is it actually NodeJS even?
- bobbygrace 13y ago
  Yup. More about the tech stack here http://blog.fogcreek.com/the-trello-tech-stack/ http://blog.fogcreek.com/the-trello-tech-stack/
- jt2190 13y ago
  Yes. Check out the interview the Trello team did on the NodeUp podcast: http://blog.fogcreek.com/trello-server-team-on-nodeup-podcast/ http://blog.fogcreek.com/trello-server-team-on-nodeup-podcas...
bobbygrace 13y ago
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.
- bobbygrace 13y ago
  er, by stable branch, i mean stable _channel_. or whatever channel.
- edwinnathaniel 13y ago
  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.
- bib971 13y ago
  Bobby, you said every app is a client of the API. I notice Trello.com consumes API from https://trello.com/1/xx 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 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 13y ago
    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 13y ago
    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 13y ago
    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.
hessenwolf 13y ago
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 13y ago

Is it actually NodeJS even?

bobbygrace 13y ago
Yup. More about the tech stack here http://blog.fogcreek.com/the-trello-tech-stack/ http://blog.fogcreek.com/the-trello-tech-stack/
jt2190 13y ago
Yes. Check out the interview the Trello team did on the NodeUp podcast: http://blog.fogcreek.com/trello-server-team-on-nodeup-podcast/ http://blog.fogcreek.com/trello-server-team-on-nodeup-podcas...

bobbygrace 13y ago

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.

bobbygrace 13y ago
er, by stable branch, i mean stable _channel_. or whatever channel.
edwinnathaniel 13y ago
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.
bib971 13y ago
Bobby, you said every app is a client of the API. I notice Trello.com consumes API from https://trello.com/1/xx 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 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 13y ago
  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 13y ago
  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 13y ago
  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.

hessenwolf 13y ago

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.