10 comments

[ 3.0 ms ] story [ 32.1 ms ] thread
One of my most popular blog posts (by a long shot) ended with the words "is dying" http://jmoses.co/2013/12/21/is-ruby-dying.html. I love figuring out ways to get people to click on my articles.

With that said, we also do a read only branch called stable that we only push to once unstable gets the OK in Jenkins. I would not say that it is dead, but just an extra safe guard. I do appreciate that book recommendation on http://www.amazon.com/gp/product/0321601912/ I have not heard of that before.

You really should be starting your titles with 'why', for that extra punch.
I would say that deployable is a lot better only if it is on master, and I tend stick with continuously deploy. I think this can only happen for situations like web based issues or etc, but I think using the same principals helps a lot. I think if its master then it should be definitely deployable.
That is one interesting topic. Thank you for bringing it up.
I think for me, if it is in the case of master, direct master should be deployable.
(comment deleted)
I would say that if it is the case of master, then it should be deployable. I may be wrong but that is what I believe, also I would stick to continuously deploy.
I find your post rather interesting. I do have a question however, Why not using a code review system like gerrit and verify every patchset by the continuous integration server?
Well, you can have Gerrit (or something similar), but this won't solve the main problem - your master branch will eventually get broken. Developers will push their because they CAN. Some of the code will pass code reviews and will be merged automatically. But sometimes (very often) they will commit and push directly to master. And you will get your build into "broken" state. And it will stay their for days.
Very interesting post there, I use Continuous integration for my project too. Even though it is time consuming, it is still a better and a reliable way to get it done.