How to Deploy Software

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.

Code branches

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

Code Review

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
    code solo.

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:

Original article

Comments are closed.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: