Organize with branches
A lot of the organizational problems surrounding deployment stems from
a lack of communication between the person deploying new code and the rest
of the people who work on the app with her. You want everyone to know the
full scope of changes you’re pushing, and you want to avoid stepping on
anyone else’s toes while you do it.
There’s a few interesting behaviors that can be used to help with
this, and they all depend on the simplest unit of deployment: the branch.
By “branch”, I mean a branch in Git, or Mercurial, or whatever you
happen to be using for version control. Cut a branch early, work on it,
and push it up to your preferred code host (GitLab, Bitbucket, etc).
You should also be using pull requests, merge requests, or other code
review to keep track of discussion on the code you’re introducing.
Deployments need to be collaborative, and using code review is a big part
of that. We’ll touch on pull requests in a bit more detail later in this
The topic of code review is long, complicated, and pretty specific to
your organization and your risk profile. I think there’s a couple
important areas common to all organizations to consider, though:
Your branch is your responsibility. The companies
I’ve seen who have tended to be more successful have all had this idea
that the ultimate responsibility of the code that gets deployed falls
upon the person or people who wrote that code. They don’t throw code
over the wall to some special person with deploy powers or testing
powers and then get up and go to lunch. Those people certainly should
be involved in the process of code review, but the most important part
of all of this is that you are responsible for your code. If
it breaks, you fix it… not your poor ops team. So don’t break it.
Start reviews early and often. You don’t need to
finish a branch before you can request comments on it. If you can open
a code review with imaginary code to gauge interest in the interface,
for example, those twenty minutes spent doing that and getting told
“no, let’s not do this” is far preferable than blowing two weeks on
that full implementation instead.
Someone needs to review. How you do this can
depend on the organization, but certainly getting another pair of eyes
on code can be really helpful. For more structured companies, you
might want to explicitly assign people to the review and demand they
review it before it goes out. For less structured companies, you could
different teams to see who’s most readily available to help you
out. In either end of the spectrum, you’re setting expectations that
someone needs to lend you a hand before storming off and deploying
Branch and deploy pacing
There’s an old joke that’s been passed around from time to time about
code review. Whenever you open a code review on a branch with six lines of
code, you’re more likely to get a lot of teammates dropping in and picking
apart those six lines left and right. But when you push a branch that
you’ve been working on for weeks, you’ll usually just get people
commenting with a quick
Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/QdLuC9A7EGk/deploying-software