11 ms·

How We Make Trello

290 points by spolsky 13y ago

basicallydan 13y ago
Fog Creek are the _kings and queens_ of dogfooding. Spolsky, you sure have nurtured a group of very loyal team players. I applaud you all. It must be really nice to work at a place where the love of the process and the product are both so strong. In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Thing. Ever. From the start, design your system this way. Good post, and an entertaining read.
- iLoch 13y ago
  While I don't think client side apps are the only way of doing things, I will say that I think client side apps will become much more popular once browsers get a little better. I love the separation of concerns that is possible with JS apps - you can have one team working on the API and one on the interface and the only place they really need to communicate is in the API documentation. Once it's all done, you've already got a fully functional and secure API (because it wasn't an afterthought) that can be used for other clients.
  - basicallydan 13y ago
    > I love the separation of concerns that is possible with JS apps - you can have one team working on the API and one on the interface and the only place they really need to communicate is in the API documentation. Yeah, me too. Apart from the actual, observable benefits you mentioned, I just find something really satisfying about the separation. Fewer hacks, easier to modify things. I think the rise in the popularity of doing things this way is largely thanks to the increase in popularity of test-driven development. Creating a client app without an API is so easy given all the tools available for mocking or faking APIs, and creating a standalone API is easy given that most of the time, you're just testing the JSON or XML output of a bunch of functions.
  - copergi 13y ago
    >you can have one team working on the API and one on the interface and the only place they really need to communicate is in the API documentation That's already how you should be working anyways. Unfortunately, most language don't seem to have support for a decent template system that makes this natural. People need to start making heist clones in their language of choice so doing things right becomes more common.
    - iLoch 13y ago
      I agree, but it's often too easy to just add another variable in your controller then modify the view, and now there's undocumented functionality. IMO the full separation is more helpful to stay DRY.
  - ChuckMcM 13y ago
    > I love the separation of concerns that is possible with ... one team working on the API and one on the interface That is, in my opinion, the larger point. If you can do solid 'interface driven design' then you enable rapid evolution on both sides of the API. One of the things Jon Wall and I did at NetApp was prototype a better split of system across the RAID and Filesystem layers, that split achieved 50% better performance across the same spindles and it allowed for innovation in the file system layer that was currently hindered by "all the hooks into the RAID stuff". The key though is picking the right layering, and not having too many. Like hashes in perl you can go crazy and suddenly everything is an API and simple things go through n layers and bog down. When people tell me they want to be architects I ask them questions about layering, that is where you separate the good systems thinkers from the not so good ones.
- reddiric 13y ago
  What does the article say to advance "single page apps" as the "best thing ever" over other application models that use a clean interface and separation of concerns between client and service?
- copergi 13y ago
  >In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Thing. Ever Those are two orthogonal things. All my sites have a complete separation of presentation from code and access a nice API to get data. Including the ones that are purely HTML and have no javascript at all. Single page apps are good for things that are actually apps. Except that I want to leave the app open, and several other apps, and not have it interfere with my normal browsing. Until browsers realize this, it is actually pretty irritating to use browser apps.
  - thedufer 13y ago
    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.
    - noblethrasher 13y ago
      >which isn't really possible if you're rendering html in the server. It's not only possible, it's pretty trivial in most cases. Just endow each user facing object with a .ToHTML() and .ToJSON(). This is actually one of the core benefits of REST, you send me a request for a resource along with some desired media type(s), and I send you back a representation in the media type of your choice (or as close as possible).
    - DEADB17 13y ago
      > which isn't really possible if you're rendering html in the server. You can have a front-end web server that is also a client of the API server and keep the separation as if it were any other API client. This is the approach I'm taking in my current project since I have to support some obsolete browsers, but more generally it lends itself to a cleaner decoupled architecture
      - 13y ago
allcentury 13y ago
I've used Trello & FogBugz over the years and we've even modeled some of our software after some of the practices they've written about. Amazing stuff!
badman_ting 13y ago
It's almost comical how nobody at my company would ever take a project this seriously. Good for them, Trello is awesome.
- smacktoward 13y ago
  Everything I've ever heard about Fog Creek indicates that they take their people seriously. Which probably makes them more likely to take their work at Fog Creek seriously. Funny how that works, huh? A lesson many, many other companies could profit from.
  - mbesto 13y ago
    I agree with your point, but it requires that you hire correct right from the beginning. Spolsky (like pg, Atwood, Fried/DHH , etc.) has his pick of the litter because of well thought out essays and large base of followers. You can't simply take this attitude without having a large pipeline of people who (1) agree with you and (2) who are good. Lesson learned - creating a community or following of people (i.e. talent marketing) is a very powerful thing.
    - exceptione 13y ago
      Well if you read what Joel says about working conditions and look at the office pics where you can see that in practice it just makes sense that fogcreek can attract the best people. Look how everybody has is own office. I still dont get it why people keep thinking that to cram puzzlers on a noisy heap with all possible (social, visual, audio) distractions saves money in the end. If Joel can offer programmers sane working conditions in NY, so can every office around the world.
    - jordo37 13y ago
      Having essays is not the only way to do it. The other way is to just be willing to wait for the right hire. At my company, we have a small engineering team so far, but we have taken a long time for each hire with the basic idea that they need to fit some key characteristics of our team. At the beginning this was actually harder to identify what was important, but now that we have a larger team there is more diversity (ideas, genders, backgrounds) and the core important tenants to us are more defined.
mikegioia 13y ago
Does anyone know how the server determines which channel the client should be using? Are they doing this check at the apache/nginx level, or on the server right after the user is authenticated, and before the client code is sent?
- gomox 13y ago
  Good question, I wondered about this as well. Channel switching would certainly create issues on data model changes in the underlying store.
  - icebraining 13y ago
    From what I understood, the API doesn't have channels, so the store only stores a single data model. The channels are only for the clients.
    - bobbygrace 13y ago
      Right. The there is only one version of the API. Multiple clients.
- dpatti 13y ago
  Because we are only delivering multiple clients, it means we only have one server version running at a time. Then, after authentication, we decide which client version you will be receiving based on your chosen channel and hashed member id in the case of multiple distributions within the channel.
haymills 13y ago
So interesting!
edwinnathaniel 13y ago
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.
sidcool 13y ago
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?
- ssi1111 13y ago
  I agree. I would pick 1 dirty branch with continuous builds and tests any time over several branches. I have worked with several branches too and it is always messy, lots of confusion and too many overheads (including the Release Manager guy). I love trello... but I don't like the branching model... :)
- morganherlocker 13y ago
  I recently switched to this approach and it works very well. No more "I want to push out this quick fix, but I have to wrap up this other thing first so I don't break the build". With github it is especially nice. I push to a remote branch, which I can see when I go to the project page. When I click merge it shows whether or not the TravisCI build passed. If it looks good, then I click to auto-merge and it's all set. It is possible to even automate away that part as well and have the whole thing merge and deploy on push if the build passes, but I am not quite ready to take the plunge yet with that (too easy to botch a production release IMHO).
- odonnellryan 13y ago
  I love to hear about workflows, what's your ideal one?
  - sidcool 13y ago
    What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production. This saves us some merging.
  - ssi1111 13y ago
    Commit to 1 dirty branch; assume it is broken and let tests prove otherwise. When tests pass, you know it is a working branch, tag and release. I skipped a few steps for simplicity. Here, merges are an exception, not the rule. This workflow won't work without automated tests... is lack of automated testing the reason to have individual branches for features and bug fixes?
takacsv 13y ago
Trello is using Trello to develop Trello. So meta :)
- AznHisoka 13y ago
  they're using Trello to write a Trello post on how they're using Trello to work on Trello.
jamessocol 13y ago
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?
- dpatti 13y ago
  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 that letting every developer deploy would not be a bad idea at all. The problem is that our team is too big to do that without creating more robust deployment tools and too small to dedicate enough time to doing so. My hope is that one day we can get there, though.
  - girvo 13y ago
    You should definitely work on the Kinect-to-deploy integration, then everyone would want to learn how to do it ;)
- brown9-2 13y ago
  I don't really see why a developer couldn't also merge changes into "the official Build repo". Or is the "release manager" just a term for the person deciding what gets released when?
- bobbygrace 13y ago
  When it's nobody's job, nobody does it. Any developer COULD do it, though.
- dodger 13y ago
  This task used to be more distributed over the server-side devs, but having a single release manager who does this most of the time and other people who do it occasionally and/or when the release manager isn't working seems to work well.
giulianob 13y ago
How difficult is it to make the backend work with both new features and old features at the same time?
- bobbygrace 13y ago
  If there are necessary API changes, we just need to push updates to the API ahead of time. The API needs to be stable and backwards compatible anyway for the mobile apps (and all third party apps).
- thedufer 13y ago
  To add to what bobby said, changes to the API are far more likely to be additions rather than actual behavior changes (except for bug fixes, which of course all clients handle fine). This makes it easy; old clients just ignore new routes/arguments.
  - steveklabnik 13y ago
    Thank you for this. I hope more people come to understand this more nuanced understanding of change. Please talk about it more!
    - irakli 13y ago
      +100
    - hamidpalo 13y ago
      Another Trello dev here. Basically, we have many clients that are consuming the API, including our mobile apps. We never change the published interface so that if you're getting some board fields that will always work. This means that we don't change the types of fields (for example string vs object) or the names of fields since that changes the published service contract. What we do instead is add more fields. A very good example of this is emoji. We added emoji support a while back and instead of changing the "text" fields to be objects or embedding HTML (gah) into them we added another field called "textData" that has the extra info. This is copy/pasted from an actual call for getting card actions: "textData": { "emoji": { "daft": "https://trello-emoji.s3.amazonaws.com/4f820a995a03e8e82d134ac4/ae846ca70bf7aa95dd3330b8fd1c70cb/art-daft-punk-steampunk-951631.gif" } }, "text": "Custom emoji! :daft:" This may not be sustainable in the long term and if it's not we'll version the API if we have to at that point. So far though, the API has proven itself to be very well designed and adaptable (thanks to @d_lec)
jcastro 13y ago
Are they on AWS or hosting your own hardware? What OS?
- tghw 13y ago
  AWS, which came about when Hurricane Sandy took down the data center's backup generator fuel supply and much of the team spent days bucket brigading diesel fuel up 17 flights of stairs.
steveklabnik 13y ago
> > The Trello API is well-written, has no bugs, and is totally rock solid. Or at > least it doesn't change very often. That means we can put out new > clients all the time without having to update the API. In fact, we can have > multiple versions of the website out at any given time.] A very counter-intuitive result: most people would not consider a stable API to let you iterate quickly!
- hiisi 13y ago
  I think the article says that the API is stable unless you have access to "Alpha" and "Beta" channels.
  - thedufer 13y ago
    Alpha and Beta channels only affect what client you get. All client versions talk to the same API, so it has to be very stable/backwards compatible.
banachtarski 13y ago
> The Trello API is well-written, has no bugs, and is totally rock solid. The no bugs claim indicates to me this wasn't written by a technical person. Or at least, not very technical.
- bobbygrace 13y ago
  It was a joke. =)
  - banachtarski 13y ago
    I reread that paragraph. In context, it doesn't seem so.
    - npizzolato 13y ago
      Read more than just the paragraph. The entire article is written in a "fun", joking style. > The revelation could result in a rippling shockwave that knocks you off your seat and may have troubling, unpredictable consequences for the time-space continuum. Possibly. > You’ve probably downloaded our iOS, Android, Kindle, and/or Windows 8 apps, and are saying to yourself, “These are very well polished apps which I have rated or will rate favorably in their respective app stores > The Trello API is well-written, has no bugs, and is totally rock solid. Or at least it doesn’t change very often. [Goes on to only reference the fact that it doesn't change very often]
      - avenger123 13y ago
        I like the passion for the product. Shines through very well.
    - tptacek 13y ago
      You figured it out. They secretly don't have any bugs. Shhh.
- deleted 13y ago
  [deleted]
somid3 13y ago
I don't get it. Why is having an API in the backend so that many clients can use it a big deal?
- morganherlocker 13y ago
  In trello's case they have a browser app, ios, and android. Having one well designed api makes these easier to build and maintain. It appears to be working pretty well for them. I use trello in browser, on an iphone, and on an ipad, and they all work together very seamlessly.
trustfundbaby 13y ago
What I'm interested in is the mechanics behind how they know were to send a user based on their channel (beta/stable/alpha). We wanted to do something like this, but we couldn't figure out how to route users to the right app server either using AWS ELBs or nginx proxying ... admittedly we didn't really spend a lot of time thinking about it though.
- thedufer 13y ago
  We do that decision-making inside the web servers. It only affects the client you get, so when someone requests a page we do a lookup on the logged-in member to decide which channel they get. API reqs don't care what channel you're on. No need for any fancy nginx proxying/etc.
aravindb 13y ago
Trello using Trello,(Inception) awesome!
kalnuezis 13y ago
Anybody using FogBugz and Kiln from Fog Creek? Both seem to be a bit outdated...
- anton_gogolev 13y ago
  In what sense are they outdated? UI-wise (which I will agree with) or feature wise?
laurenstill 13y ago
This is great and all, but I really wish I knew why they won't make the audit logs accessible to users. If someone has a hack for this, I'm all ears. Need it for compliance documentation.
jw2013 13y ago
These tech intros are pretty cool, yet can I ask how does the team acquire users? That seems to be harder than the tech challenges for Trello IMHO.
nick2021 13y ago
Should be titled "How We Don't Care".
nevster 13y ago
I'd like to be able to write like this. It made me LOL.
chrismorgan 13y ago
I like the lighthearted approach to cross-selling in the article. ☺
deleted 13y ago
[deleted]

290 points by spolsky 13y ago

Fog Creek are the _kings and queens_ of dogfooding. Spolsky, you sure have nurtured a group of very loyal team players. I applaud you all. It must be really nice to work at a place where the love of the process and the product are both so strong. In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Thing. Ever. From the start, design your system this way. Good post, and an entertaining read.

iLoch 13y ago
While I don't think client side apps are the only way of doing things, I will say that I think client side apps will become much more popular once browsers get a little better. I love the separation of concerns that is possible with JS apps - you can have one team working on the API and one on the interface and the only place they really need to communicate is in the API documentation. Once it's all done, you've already got a fully functional and secure API (because it wasn't an afterthought) that can be used for other clients.
- basicallydan 13y ago
  > I love the separation of concerns that is possible with JS apps - you can have one team working on the API and one on the interface and the only place they really need to communicate is in the API documentation. Yeah, me too. Apart from the actual, observable benefits you mentioned, I just find something really satisfying about the separation. Fewer hacks, easier to modify things. I think the rise in the popularity of doing things this way is largely thanks to the increase in popularity of test-driven development. Creating a client app without an API is so easy given all the tools available for mocking or faking APIs, and creating a standalone API is easy given that most of the time, you're just testing the JSON or XML output of a bunch of functions.
- copergi 13y ago
  >you can have one team working on the API and one on the interface and the only place they really need to communicate is in the API documentation That's already how you should be working anyways. Unfortunately, most language don't seem to have support for a decent template system that makes this natural. People need to start making heist clones in their language of choice so doing things right becomes more common.
  - iLoch 13y ago
    I agree, but it's often too easy to just add another variable in your controller then modify the view, and now there's undocumented functionality. IMO the full separation is more helpful to stay DRY.
- ChuckMcM 13y ago
  > I love the separation of concerns that is possible with ... one team working on the API and one on the interface That is, in my opinion, the larger point. If you can do solid 'interface driven design' then you enable rapid evolution on both sides of the API. One of the things Jon Wall and I did at NetApp was prototype a better split of system across the RAID and Filesystem layers, that split achieved 50% better performance across the same spindles and it allowed for innovation in the file system layer that was currently hindered by "all the hooks into the RAID stuff". The key though is picking the right layering, and not having too many. Like hashes in perl you can go crazy and suddenly everything is an API and simple things go through n layers and bog down. When people tell me they want to be architects I ask them questions about layering, that is where you separate the good systems thinkers from the not so good ones.
reddiric 13y ago
What does the article say to advance "single page apps" as the "best thing ever" over other application models that use a clean interface and separation of concerns between client and service?
copergi 13y ago
>In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Thing. Ever Those are two orthogonal things. All my sites have a complete separation of presentation from code and access a nice API to get data. Including the ones that are purely HTML and have no javascript at all. Single page apps are good for things that are actually apps. Except that I want to leave the app open, and several other apps, and not have it interfere with my normal browsing. Until browsers realize this, it is actually pretty irritating to use browser apps.
- thedufer 13y ago
  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.
  - noblethrasher 13y ago
    >which isn't really possible if you're rendering html in the server. It's not only possible, it's pretty trivial in most cases. Just endow each user facing object with a .ToHTML() and .ToJSON(). This is actually one of the core benefits of REST, you send me a request for a resource along with some desired media type(s), and I send you back a representation in the media type of your choice (or as close as possible).
  - DEADB17 13y ago
    > which isn't really possible if you're rendering html in the server. You can have a front-end web server that is also a client of the API server and keep the separation as if it were any other API client. This is the approach I'm taking in my current project since I have to support some obsolete browsers, but more generally it lends itself to a cleaner decoupled architecture
    - 13y ago

allcentury 13y ago

I've used Trello & FogBugz over the years and we've even modeled some of our software after some of the practices they've written about. Amazing stuff!

badman_ting 13y ago

It's almost comical how nobody at my company would ever take a project this seriously. Good for them, Trello is awesome.

smacktoward 13y ago
Everything I've ever heard about Fog Creek indicates that they take their people seriously. Which probably makes them more likely to take their work at Fog Creek seriously. Funny how that works, huh? A lesson many, many other companies could profit from.
- mbesto 13y ago
  I agree with your point, but it requires that you hire correct right from the beginning. Spolsky (like pg, Atwood, Fried/DHH , etc.) has his pick of the litter because of well thought out essays and large base of followers. You can't simply take this attitude without having a large pipeline of people who (1) agree with you and (2) who are good. Lesson learned - creating a community or following of people (i.e. talent marketing) is a very powerful thing.
  - exceptione 13y ago
    Well if you read what Joel says about working conditions and look at the office pics where you can see that in practice it just makes sense that fogcreek can attract the best people. Look how everybody has is own office. I still dont get it why people keep thinking that to cram puzzlers on a noisy heap with all possible (social, visual, audio) distractions saves money in the end. If Joel can offer programmers sane working conditions in NY, so can every office around the world.
  - jordo37 13y ago
    Having essays is not the only way to do it. The other way is to just be willing to wait for the right hire. At my company, we have a small engineering team so far, but we have taken a long time for each hire with the basic idea that they need to fit some key characteristics of our team. At the beginning this was actually harder to identify what was important, but now that we have a larger team there is more diversity (ideas, genders, backgrounds) and the core important tenants to us are more defined.

mikegioia 13y ago

Does anyone know how the server determines which channel the client should be using? Are they doing this check at the apache/nginx level, or on the server right after the user is authenticated, and before the client code is sent?

gomox 13y ago
Good question, I wondered about this as well. Channel switching would certainly create issues on data model changes in the underlying store.
- icebraining 13y ago
  From what I understood, the API doesn't have channels, so the store only stores a single data model. The channels are only for the clients.
  - bobbygrace 13y ago
    Right. The there is only one version of the API. Multiple clients.
dpatti 13y ago
Because we are only delivering multiple clients, it means we only have one server version running at a time. Then, after authentication, we decide which client version you will be receiving based on your chosen channel and hashed member id in the case of multiple distributions within the channel.

haymills 13y ago

So interesting!

edwinnathaniel 13y ago

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.

sidcool 13y ago

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?

ssi1111 13y ago
I agree. I would pick 1 dirty branch with continuous builds and tests any time over several branches. I have worked with several branches too and it is always messy, lots of confusion and too many overheads (including the Release Manager guy). I love trello... but I don't like the branching model... :)
morganherlocker 13y ago
I recently switched to this approach and it works very well. No more "I want to push out this quick fix, but I have to wrap up this other thing first so I don't break the build". With github it is especially nice. I push to a remote branch, which I can see when I go to the project page. When I click merge it shows whether or not the TravisCI build passed. If it looks good, then I click to auto-merge and it's all set. It is possible to even automate away that part as well and have the whole thing merge and deploy on push if the build passes, but I am not quite ready to take the plunge yet with that (too easy to botch a production release IMHO).
odonnellryan 13y ago
I love to hear about workflows, what's your ideal one?
- sidcool 13y ago
  What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production. This saves us some merging.
- ssi1111 13y ago
  Commit to 1 dirty branch; assume it is broken and let tests prove otherwise. When tests pass, you know it is a working branch, tag and release. I skipped a few steps for simplicity. Here, merges are an exception, not the rule. This workflow won't work without automated tests... is lack of automated testing the reason to have individual branches for features and bug fixes?

takacsv 13y ago

Trello is using Trello to develop Trello. So meta :)

AznHisoka 13y ago
they're using Trello to write a Trello post on how they're using Trello to work on Trello.

jamessocol 13y ago

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?

dpatti 13y ago
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 that letting every developer deploy would not be a bad idea at all. The problem is that our team is too big to do that without creating more robust deployment tools and too small to dedicate enough time to doing so. My hope is that one day we can get there, though.
- girvo 13y ago
  You should definitely work on the Kinect-to-deploy integration, then everyone would want to learn how to do it ;)
brown9-2 13y ago
I don't really see why a developer couldn't also merge changes into "the official Build repo". Or is the "release manager" just a term for the person deciding what gets released when?
bobbygrace 13y ago
When it's nobody's job, nobody does it. Any developer COULD do it, though.
dodger 13y ago
This task used to be more distributed over the server-side devs, but having a single release manager who does this most of the time and other people who do it occasionally and/or when the release manager isn't working seems to work well.

giulianob 13y ago

How difficult is it to make the backend work with both new features and old features at the same time?

bobbygrace 13y ago
If there are necessary API changes, we just need to push updates to the API ahead of time. The API needs to be stable and backwards compatible anyway for the mobile apps (and all third party apps).
thedufer 13y ago
To add to what bobby said, changes to the API are far more likely to be additions rather than actual behavior changes (except for bug fixes, which of course all clients handle fine). This makes it easy; old clients just ignore new routes/arguments.
- steveklabnik 13y ago
  Thank you for this. I hope more people come to understand this more nuanced understanding of change. Please talk about it more!
  - irakli 13y ago
    +100
  - hamidpalo 13y ago
    Another Trello dev here. Basically, we have many clients that are consuming the API, including our mobile apps. We never change the published interface so that if you're getting some board fields that will always work. This means that we don't change the types of fields (for example string vs object) or the names of fields since that changes the published service contract. What we do instead is add more fields. A very good example of this is emoji. We added emoji support a while back and instead of changing the "text" fields to be objects or embedding HTML (gah) into them we added another field called "textData" that has the extra info. This is copy/pasted from an actual call for getting card actions: "textData": { "emoji": { "daft": "https://trello-emoji.s3.amazonaws.com/4f820a995a03e8e82d134ac4/ae846ca70bf7aa95dd3330b8fd1c70cb/art-daft-punk-steampunk-951631.gif" } }, "text": "Custom emoji! :daft:" This may not be sustainable in the long term and if it's not we'll version the API if we have to at that point. So far though, the API has proven itself to be very well designed and adaptable (thanks to @d_lec)

jcastro 13y ago

Are they on AWS or hosting your own hardware? What OS?

tghw 13y ago
AWS, which came about when Hurricane Sandy took down the data center's backup generator fuel supply and much of the team spent days bucket brigading diesel fuel up 17 flights of stairs.

steveklabnik 13y ago

> > The Trello API is well-written, has no bugs, and is totally rock solid. Or at > least it doesn't change very often. That means we can put out new > clients all the time without having to update the API. In fact, we can have > multiple versions of the website out at any given time.] A very counter-intuitive result: most people would not consider a stable API to let you iterate quickly!

hiisi 13y ago
I think the article says that the API is stable unless you have access to "Alpha" and "Beta" channels.
- thedufer 13y ago
  Alpha and Beta channels only affect what client you get. All client versions talk to the same API, so it has to be very stable/backwards compatible.

banachtarski 13y ago

> The Trello API is well-written, has no bugs, and is totally rock solid. The no bugs claim indicates to me this wasn't written by a technical person. Or at least, not very technical.

bobbygrace 13y ago
It was a joke. =)
- banachtarski 13y ago
  I reread that paragraph. In context, it doesn't seem so.
  - npizzolato 13y ago
    Read more than just the paragraph. The entire article is written in a "fun", joking style. > The revelation could result in a rippling shockwave that knocks you off your seat and may have troubling, unpredictable consequences for the time-space continuum. Possibly. > You’ve probably downloaded our iOS, Android, Kindle, and/or Windows 8 apps, and are saying to yourself, “These are very well polished apps which I have rated or will rate favorably in their respective app stores > The Trello API is well-written, has no bugs, and is totally rock solid. Or at least it doesn’t change very often. [Goes on to only reference the fact that it doesn't change very often]
    - avenger123 13y ago
      I like the passion for the product. Shines through very well.
  - tptacek 13y ago
    You figured it out. They secretly don't have any bugs. Shhh.
deleted 13y ago
[deleted]

somid3 13y ago

I don't get it. Why is having an API in the backend so that many clients can use it a big deal?

morganherlocker 13y ago
In trello's case they have a browser app, ios, and android. Having one well designed api makes these easier to build and maintain. It appears to be working pretty well for them. I use trello in browser, on an iphone, and on an ipad, and they all work together very seamlessly.

trustfundbaby 13y ago

What I'm interested in is the mechanics behind how they know were to send a user based on their channel (beta/stable/alpha). We wanted to do something like this, but we couldn't figure out how to route users to the right app server either using AWS ELBs or nginx proxying ... admittedly we didn't really spend a lot of time thinking about it though.

thedufer 13y ago
We do that decision-making inside the web servers. It only affects the client you get, so when someone requests a page we do a lookup on the logged-in member to decide which channel they get. API reqs don't care what channel you're on. No need for any fancy nginx proxying/etc.

aravindb 13y ago

Trello using Trello,(Inception) awesome!

kalnuezis 13y ago

Anybody using FogBugz and Kiln from Fog Creek? Both seem to be a bit outdated...

anton_gogolev 13y ago
In what sense are they outdated? UI-wise (which I will agree with) or feature wise?

laurenstill 13y ago

This is great and all, but I really wish I knew why they won't make the audit logs accessible to users. If someone has a hack for this, I'm all ears. Need it for compliance documentation.

jw2013 13y ago

These tech intros are pretty cool, yet can I ask how does the team acquire users? That seems to be harder than the tech challenges for Trello IMHO.

nick2021 13y ago

Should be titled "How We Don't Care".

nevster 13y ago

I'd like to be able to write like this. It made me LOL.

chrismorgan 13y ago

I like the lighthearted approach to cross-selling in the article. ☺

deleted 13y ago

[deleted]