Basically, these things are necessary to be together for things to work efficiently : Trunk-based development, Pair Programming, heavy test automation (preferably TDD), Feature toggles, Continuous integration and deployment. Putting a human somewhere between developer commiting code into master and it being deployed into production dramatically slows down cycle time and thus team's ability to innovate and quickly respond to issues.
I know I'm late to this party but I don't think you need to, must have, a human release manager between the dev and release to prod. There needs to be a process but if mature enough you should be able to have that be somewhat automated. If you have decoupled release from deploy processes this should be even more true. Am I living in la la land?
I'm so happy that I landed into this video and got the chance of knowing Craig while enjoying every minute of him sharing his experience. p.s. sorry Dave but in every interruption i just said "come on Dave, please let him talk! he already knows what he is talking about and nails it".
Yeah, as Helmut pointed out a while back, I could have used a bit less espresso that day. Craig is an accomplished presenter to diverse audiences, so there wasn't much need for me to restate, translate or elaborate. Glad you found Craig. Here's another talk he gave that's super-valuable in under 30 minutes: www.usenix.org/conference/lisa18/presentation/sebenik
For me actually it was great that there was a discussion going on. You guys explained the same thing many times more than once, and it made the video much more understandable. For experts sure, might be boring, but for learners helpful imho. Thanks! Great content!
I would recommend for Dave to skip on the espresso 😂! It was a great conversation but it was hard to watch Dave repeat or extend on the answers that Craig was giving. You could tell that Craig had more to say but Dave was taking over. Just my personal observation, I am not sure if the other conversations are the same or this was a just one-off.
Totally fair feedback Helmut. With someone who explains it as well as Craig, I could have reigned in the restating and amplifying. Way back a lifetime or two, I was a systems trainer for non-technical audiences, and then a systems analyst/project manager praised for translating technical details into language business users could understand. When you have a hammer, the whole world can look like a nail :-) As for other conversations, in this one on forming a hypothesis for an experiment, I think I clock in at
working with trunk based branches is like working with svn or cvs, you will have a lot of conflicts that git use to solve by merging branches, as there are many developer pushing their code. if the goal is to push code in the master as soon as possible this can be achieved also with feature branches, by doing multiple merging without deleting the branch, not necessary at the end of the feature, like you will push into the master not necessary at the end of your development task.
This type of developments helps with feature flags but at end of a year worth of development ure left with hundreds of feature flags which are art time built on top of each other with dependencies leaving u like in a control center with hundreds of toggles
Basically, these things are necessary to be together for things to work efficiently : Trunk-based development, Pair Programming, heavy test automation (preferably TDD), Feature toggles, Continuous integration and deployment. Putting a human somewhere between developer commiting code into master and it being deployed into production dramatically slows down cycle time and thus team's ability to innovate and quickly respond to issues.
This is the kind of clear straight definition I was looking for. Thanks!
I know I'm late to this party but I don't think you need to, must have, a human release manager between the dev and release to prod. There needs to be a process but if mature enough you should be able to have that be somewhat automated.
If you have decoupled release from deploy processes this should be even more true.
Am I living in la la land?
I'm so happy that I landed into this video and got the chance of knowing Craig while enjoying every minute of him sharing his experience.
p.s. sorry Dave but in every interruption i just said "come on Dave, please let him talk! he already knows what he is talking about and nails it".
Yeah, as Helmut pointed out a while back, I could have used a bit less espresso that day. Craig is an accomplished presenter to diverse audiences, so there wasn't much need for me to restate, translate or elaborate. Glad you found Craig. Here's another talk he gave that's super-valuable in under 30 minutes: www.usenix.org/conference/lisa18/presentation/sebenik
For me actually it was great that there was a discussion going on. You guys explained the same thing many times more than once, and it made the video much more understandable. For experts sure, might be boring, but for learners helpful imho.
Thanks! Great content!
I would recommend for Dave to skip on the espresso 😂! It was a great conversation but it was hard to watch Dave repeat or extend on the answers that Craig was giving. You could tell that Craig had more to say but Dave was taking over. Just my personal observation, I am not sure if the other conversations are the same or this was a just one-off.
Totally fair feedback Helmut. With someone who explains it as well as Craig, I could have reigned in the restating and amplifying. Way back a lifetime or two, I was a systems trainer for non-technical audiences, and then a systems analyst/project manager praised for translating technical details into language business users could understand. When you have a hammer, the whole world can look like a nail :-) As for other conversations, in this one on forming a hypothesis for an experiment, I think I clock in at
15:17 Hotfixes Dedicated hotfix branch. By keeping the Head of master and prod delta minimum, the need for hotfix branch essentially goes to zero
working with trunk based branches is like working with svn or cvs, you will have a lot of conflicts that git use to solve by merging branches, as there are many developer pushing their code. if the goal is to push code in the master as soon as possible this can be achieved also with feature branches, by doing multiple merging without deleting the branch, not necessary at the end of the feature, like you will push into the master not necessary at the end of your development task.
This type of developments helps with feature flags but at end of a year worth of development ure left with hundreds of feature flags which are art time built on top of each other with dependencies leaving u like in a control center with hundreds of toggles
oof, "release manager" and "cherrypicking" raised my pulse instantly. run if you have to deal with either on a daily basis and never look back
Instead of "with me today is Craig" for a second I thought you called him "Continuous Craig" which would be an awesome nick name.
8:54 That's being done by the Release manager
Excellent content. Cheers!
Wait.... 2 pizzas can feed 10 people?
Don't drink espresso from metal cups!
But great talk, nevertheless!
The guy looks just like Tobin Bell from the SAW