Re:Continuous Delivery
by tosh on Wednesday May 22, 2013 @10:31PM
(#5755009)
Brilliant write-up on the benefits of continuous delivery.
Especially the part on delivering value as fast as possible (& drastically changing Cost of Delay) is a very powerful concept that generates enormous economic value (something that engineers often don't immediately think about in comparison to productivity).
Re:Continuous Delivery
by brett-cawley on Thursday May 23, 2013 @05:07AM
(#5755896)
Good post! Though from experience it's never worked as smoothly as described when in a team setting. "Oh, you forgot to check features 1-40 in all major browsers?" Rollback button : engage
Re:Continuous Delivery
by rdegges on Thursday May 23, 2013 @08:31AM
(#5756432)
I use rollback liberally in team settings -- I also do a lot of my work on Heroku, so if anything breaks we do a `heroku rollback` immediately.
Usually though -- we're very careful about deploying stuff live. We autodeploy our develop branch to a testing Heroku project, and if that's good, we merge to master.
Re:Continuous Delivery
by rdegges on Thursday May 23, 2013 @08:31AM
(#5756434)
Depends on what you need. I tend to have CD setup for both my develop and master branches, and everything else gets worked on / tested locally only (until those changes are merged).
But I had trouble buying the premise of:
Nothing in Jenkins can be configured in just a half hour. ;)Usually takes me 20 minutes ish.
Especially the part on delivering value as fast as possible (& drastically changing Cost of Delay) is a very powerful concept that generates enormous economic value (something that engineers often don't immediately think about in comparison to productivity).
More info from: http://blogs.atlassian.com/2013/05/bamboo-beta-program/
Usually though -- we're very careful about deploying stuff live. We autodeploy our develop branch to a testing Heroku project, and if that's good, we merge to master.
Is that how continuous deployment is usually set up?