61–70 of 120 posts
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?
I love trello... but I don't like the branching model... :)
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…
>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…
That said, I agree that making something into a single page app just to get this separation isn't going to be useful.
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?
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.
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?
Yes, more or less a new branch for each fix. But with git and Kiln, it's really not a drag at all; the merges are generally really easy and mostly performed by our release manager when the card makes it to 'Ready to Merge'.
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?
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).
I don't get it. Why is having an API in the backend so that many clients can use it a big deal?
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?
I love to hear about workflows, what's your ideal one?
This workflow won't work without automated tests... is lack of automated testing the reason to have individual branches for features and bug fixes?
Earlier quoted context omitted.
Yes, more or less a new branch for each fix. But with git and Kiln, it's really not a drag at all; the merges are generally really easy and mostly performed by our release manager when the card makes it to 'Ready to Merge'.
How do you test the fixes? Which branch gets deployed to the test environment?
Trello is using Trello to develop Trello. So meta :)
Earlier quoted context omitted.
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…
>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.