I gave a talk today at DevOpsDays Raleigh entitled It’s Not Continuous Delivery If You Can’t Deploy Right Now (slides here). I had some great questions later in the day so wanted to add a bit more followup…
I’m not a fan of using how often a team deploys as a metric.
John Willis pointed out that lead time for changes is a great metric, and the ability to deploy quickly can have an effect on that. I couldn’t agree more.
I also was given an example later in the day about a particular instance where a consecutive set of changes needed to be applied in a certain order. The faster those changes could be deployed, the smaller (and hence less risky) that deployment would be. Again, awesome example of a need to deploy quickly.
When I say I’m not a fan of the “how often I deploy” metric, I mean as a stand alone measure. If it enables a business goal, awesome! By itself, not so much.
Trunk (master/mainline/other) based development.
There was a question about how to do code reviews when you’re doing trunk based development. I commonly see a few ways:
Pairing. I’m a big fan of this anyway, but a lot of teams will use this as the code review. This is especially true when it’s actual “move the keyboard from person to person” pairing.
Pull Requests. When I’m working on something under Git’s control, the first thing I do is type ‘checkout -b branchname’, creating a new branch. Each day (at least) that code can be submitted as a pull request for review. A good example of this is practice is the DevOpsDays.org website. You can see the contribution guide here.
The biggest thing I want to avoid when advising people to avoid feature branches are long lived branches. It’s not at all uncommon for me to see branches which last for days, weeks and even longer before any work goes back into trunk. This is a recipe for disaster.
I’m not saying don’t create branches, I’m saying push code back in at least daily. My go to resource for details about this is Martin Fowler’s excellent article on the topic, found here.
Another really good resource for more on trunk based development is, you guessed it, trunkbaseddevelopment.com.
Pipelines of a different length
I show a version of the following fairly often…
The idea here is that we may have longer running tests which we want to make sure have passed before we’re willing to deploy to production. They are performance related in this image, but could be compliance or really anything else.
The question came up; “Doesn’t this mean I could deploy to staging several times while those tests are running?” Yes, you could.
In this diagram the purpose of staging is to test the deployment of our software on a production like environment. So, if production is going to be a cluster, staging needs to be a cluster, although potentially not as big. Like all of our tests, we want to know as quickly as possible if we have a failure, even if that build isn’t going to end up going out to the world.
Shameless plug, this use case is one reason my company ThoughtWorks created GoCD. It will enforce the fact that the build which gets deployed to production has passed all of the pipelines in it’s value stream, even if they don’t run at the same speed.
Thanks for the feedback and questions!
I can’t say how valuable it is to have these types of questions asked after a presentation. It allows me to make it better the next time!
We just wrapped up DevOpsDays Seattle. It was awesome. We had a bunch of truly engaging and informative talks. We also had one talk that really pissed me off.
I want to be clear here… I’m not upset with the speaker, or the content of the talk. I’m upset with the idiots who made the talk necessary.
For those of us that have implemented Continuous Delivery and moved to (or solidified) working in a sharing culture (DevOps), many of the concepts are old hat. We’re all very excited to learn about the latest way to manage thousands of docker containers running in multiple data centers. We talk about monitoring systems that allow us to make fine grained business decisions based on very small, but very important, pieces of data.
Another organization launched today offering DevOps certifications. We’ll skip the fact that DevOps is supposed to be about culture (something pretty hard to quantify, let alone certify) and focus on the “certification” part. Continue reading “Certifications Suck”
I’m totally guilty of using the term “guys” on a fairly regular basis, even when giving talks in public. It’s very close to my “um”.
I want to stop. I really do. So, I’m giving myself an incentive.
I’ll donate $5 to Black Girls Code for every time I use the term “guys” in a public talk. Yes, I’m starting only with public talks so I can still pay the mortgage.
- Please don’t interrupt an actual talk, let me know afterwards
- This only applies to talks in the future, no fair going back in time to youtube
- It’s $5 per usage, not $5 per person who catches me (again, gotta pay the mortgage)
Do you use the word “guys” when talking to groups of people? Join me!