41–50 of 120 posts
Earlier quoted context omitted.
You are right, that would be the opposite extreme. 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.
Is merging painful enough for you team that it's worth avoiding?
Earlier quoted context omitted.
That's how I work as well. Not a huge problem if you're using git, since branches are cheap and merges are easy.
We use Subversion mostly, I guess that's why the merging is a hassle.
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?
Earlier quoted context omitted.
Is merging painful enough for you team that it's worth avoiding?
It can't be avoided, but we do tend to try and minimize it.
Are they on AWS or hosting your own hardware? What OS?
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…
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.
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.
A very counter-intuitive result: most people would not consider a stable API to let you iterate quickly!
Earlier quoted context omitted.
That's how I work as well. Not a huge problem if you're using git, since branches are cheap and merges are easy.
We use Subversion mostly, I guess that's why the merging is a hassle.
How difficult is it to make the backend work with both new features and old features at the same time?
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.