How We Make Trello • Hacker News Board

Re: How We Make Trello

#21

Post by yen223 » Thu, Mar 13, 2014, 5:04 PM UTC

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?

That's how I work as well. Not a huge problem if you're using git, since branches are cheap and merges are easy.

Re: How We Make Trello

#22

Post by bobbygrace » Thu, Mar 13, 2014, 5:09 PM UTC

icebraining wrote: post #15

gomox wrote: post #7

Earlier quoted context omitted.

Good question, I wondered about this as well. Channel switching would certainly create issues on data model changes in the underlying store.

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.

Right. The there is only one version of the API. Multiple clients.

Re: How We Make Trello

#23

Post by takacsv » Thu, Mar 13, 2014, 5:10 PM UTC

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

Re: How We Make Trello

#24

Post by bobbygrace » Thu, Mar 13, 2014, 5:15 PM UTC

tel wrote: post #18

edwinnathaniel wrote: post #11

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 guy…

Is it actually NodeJS even?

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

Re: How We Make Trello

#25

Post by upops » Thu, Mar 13, 2014, 5:19 PM UTC

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 Driessen, http://nvie.com/posts/a-successful-git-branching-model/.

Re: How We Make Trello

#26

Post by jamessocol » Thu, Mar 13, 2014, 5:20 PM UTC

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?

Re: How We Make Trello

#27

Post by giulianob » Thu, Mar 13, 2014, 5:23 PM UTC

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

Re: How We Make Trello

#28

Post by ChuckMcM » Thu, Mar 13, 2014, 5:23 PM UTC

iLoch wrote: post #5

basicallydan wrote: post #2

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. Fro…

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 alre…

   > 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.

Re: How We Make Trello

#29

Post by brown9-2 » Thu, Mar 13, 2014, 5:25 PM UTC

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?

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?

Re: How We Make Trello

#30

Post by bobbygrace » Thu, Mar 13, 2014, 5:26 PM UTC

giulianob wrote: post #27

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

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