Archived video

This video is archived and won't be updated. We're keeping it online for now as a courtesy.

Alternate resources: 

Pantheon Branching and Multidev

Video loading...

  • 0:00
    Manage Drupal Sites with Pantheon Pantheon Branching and Multidev Addison Berry
  • 0:09
    One of the really neat features that comes with Pantheon
  • 0:12
    is Multidev, so let's talk about branching and Multidev.
  • 0:18
    So in this lesson, we're going to explain what the Multidev feature is
  • 0:22
    and how that works, briefly, as an overview.
  • 0:24
    We'll talk about the benefits and why you might want to use this feature,
  • 0:27
    and then we're going to explain some of the terminology
  • 0:30
    that is associated with Multidev.
  • 0:34
    So what is it? Multidev is the ability for you to fork an entire development site.
  • 0:40
    Do your development work in that sort of isolated environment,
  • 0:44
    and then merge your code changes back into the main development site
  • 0:48
    that everybody else is using for development.
  • 0:51
    Now, why would you want to do this? Well, the reason that this is really useful.
  • 0:57
    it's standardized sort of best practices for managing and merging code.
  • 1:02
    Each developer has their own environment.
  • 1:05
    They have their own site that is running all of the same things
  • 1:10
    from the code base that you forked— it has the database,
  • 1:13
    it has the files, and you have an actual, working site
  • 1:16
    that they can use without having to set anything up locally,
  • 1:19
    and this keeps it very standardized.
  • 1:21
    It also means everything's running on the same software,
  • 1:24
    so the site is identical to, say, what the live site is being hosted on as well.
  • 1:28
    So everybody has the identical environment,
  • 1:32
    and sometimes when you have local development work,
  • 1:35
    you end up with things being a little bit different on this person's laptop
  • 1:38
    versus that person's desktop, and that can end up creating some problems.
  • 1:42
    This way, you have everything the same for all developers,
  • 1:46
    regardless of what they're working on.
  • 1:50
    So now, if we look at this simulation to sort of the standard Pantheon workflow, right,
  • 1:54
    you get 3 environments— you get Dev, Test, and Live,
  • 1:57
    and normally, you would just do your work and save your changes to Dev,
  • 2:03
    and then you can push it forward, right?
  • 2:05
    So you have that one Dev environment site where you can break things
  • 2:08
    and mess things up and play with it.
  • 2:11
    With Multidev, you have that same system in place.
  • 2:15
    You still have Dev, Test and Live. In addition,
  • 2:18
    you can have a whole bunch of environments
  • 2:21
    that are all getting merged into that one Dev environment.
  • 2:25
    So instead of being stuck with that one Dev site,
  • 2:28
    you can actually have a whole bunch of different Dev sites,
  • 2:31
    and each Dev site can be focused on its own task.
  • 2:35
    You don't need to be mixing and matching everything together,
  • 2:38
    stepping on each others' toes while trying to get work done.
  • 2:41
    We're going to do a brief review of terminology.
  • 2:45
    A lot of the terminology that you will see in Multidev
  • 2:48
    is directly based on the terminology in Git,
  • 2:52
    because underlying, that's what's going on in terms of the code base,
  • 2:56
    which is what's really being worked on here.
  • 2:58
    So we're just going to briefly cover these terms
  • 3:00
    just so that everybody's on the same page with these.
  • 3:03
    So environment is what you get— your environments that you get with Pantheon,
  • 3:09
    so that is the code, the database, the files—that's the whole thing.
  • 3:12
    It's the living, running site, and in Pantheon,
  • 3:16
    by default, you always get a dev, a test, and a live environment.
  • 3:19
    In the code side of things in the development world, normally, forking is copying the source code
  • 3:25
    so you can then modify it and start doing what you want
  • 3:27
    with that code.
  • 3:29
    With Pantheon, when you fork an environment,
  • 3:32
    you're basically creating an exact copy of that environment,
  • 3:35
    including the files and the database, not just the code.
  • 3:37
    You have an entire working site with the fork.
  • 3:40
    So branches and commits— so a commit is simply recording
  • 3:46
    a snapshot in time of your code to a history.
  • 3:50
    It's keeping track of all of the changes that you have been making to your code.
  • 3:54
    So if we look at this very simple diagram,
  • 3:56
    we have one commit at the beginning,
  • 4:00
    and then we follow along the line. I do a bunch of code.
  • 4:02
    I'm making changes, and then I want to save
  • 4:05
    the work that I've done, and I commit that,
  • 4:07
    and that's number two, and you will just keep doing that.
  • 4:10
    So it's just the snapshot of essentially when you specifically say,
  • 4:13
    okay, I'm done with this set of work, and I want to get a snapshot
  • 4:17
    of this point in time right now, so these are the commits.
  • 4:20
    Now, a branch is a movable pointer to a set of commits—
  • 4:23
    it's a very fancy definition here.
  • 4:26
    The important thing here is it allows independent development and history.
  • 4:29
    Essentially, what this is, when you have a history,
  • 4:32
    when you have this timeline of commits,
  • 4:35
    one set of that is a branch, right?
  • 4:38
    So it's a bunch of different commits that has the entire sort of timeline
  • 4:42
    of the code changes that you've been making.
  • 4:44
    Now, master is the name of the default branch.
  • 4:47
    So when you first create something in git,
  • 4:50
    or when you first create a new environment in Pantheon,
  • 4:54
    the code base starts off with its first branch,
  • 5:00
    and that first default branch is always referred to as the master.
  • 5:04
    So when you see master, that is sort of the main code base
  • 5:08
    that you start with when you get going.
  • 5:11
    So now you can see, what I've done in this diagram
  • 5:16
    is we had the master branch, but what I did is,
  • 5:19
    I made an additional branch from master.
  • 5:22
    I basically copied master. I created a new branch
  • 5:25
    called bugfix232, for ticket 232,
  • 5:29
    and now I can start to begin to work independently
  • 5:33
    in this bugfix branch and not make any mistakes
  • 5:37
    or mess things up in that master branch.
  • 5:39
    So now I have my own code base and I'm not messing with things
  • 5:43
    that are happening in master, and you can create
  • 5:45
    as many branches as you want.
  • 5:48
    Now, if you're moving along and you're working on your code—
  • 5:52
    so in this example, so we have a master,
  • 5:55
    and master has two commits here, M1, M2.
  • 5:57
    And then I'm creating a branch; so let's say I'm creating a bug fix branch here,
  • 6:01
    and this is my first commit, B1, in this new branch
  • 6:05
    that I've created, and I'm working along.
  • 6:09
    I'm changing things. I'm fixing it.
  • 6:11
    I fix the bug, but now that I've fixed the bug, I'm in my own isolated environment.
  • 6:14
    How do I get my stuff back to master,
  • 6:16
    which is where it belongs?
  • 6:18
    And this is what we call merging.
  • 6:20
    So after I've done my changes in my branch,
  • 6:23
    I'm going to merge all of that back into master,
  • 6:27
    and that would be yet another commit here, M3,
  • 6:30
    on the master branch, and so forth, and so on.
  • 6:33
    I could continue to work in this branch if I wanted to,
  • 6:36
    or I could decide to just close the branch because its work is done now.
  • 6:40
    You can go either way there.
  • 6:42
    Another important thing to understand with merging
  • 6:44
    is that merging is between branches— it has nothing necessarily to do
  • 6:48
    with master versus bug fix branch versus feature branch.
  • 6:51
    You can merge any branch with any other branch,
  • 6:54
    and often you will need to merge changes that have happened in master
  • 6:57
    back into your development branches to make sure you're staying up to date.
  • 7:01
    So that's essentially what's going on in terms of having branches
  • 7:05
    and merging them back together again.
  • 7:08
    So that's the terminology that you're going to be seeing
  • 7:12
    when working with Multidev.
  • 7:14
    Now, just to kind of close things out, I wanted to give a little snapshot,
  • 7:17
    a little glimpse at the Multidev sort of management,
  • 7:21
    what's going on.
  • 7:23
    So we're creating these environments, these total websites over here,
  • 7:25
    and there's Git code happening in the background.
  • 7:27
    You get this dashboard here that gives you a nice overview
  • 7:29
    of everything that's going on with Multidev.
  • 7:32
    So in this instance, I have a list
  • 7:34
    of all of the different development environments that are currently going on
  • 7:38
    with this particular site.
  • 7:40
    I could also look at just the Git branches— Git branching.
  • 7:42
    You could also still do that, but you wouldn't have an entire site.
  • 7:45
    The environments is the entire website with the database and the files and everything
  • 7:49
    that goes with it, which is what makes it handy.
  • 7:51
    And you can see I have some interfaces here for merging
  • 7:54
    and keeping track of how many commits we have
  • 7:57
    and where things are in relation to master.
  • 8:00
    And so to recap, we explained briefly
  • 8:04
    what Multidev is, we talked about some of the benefits of it,
  • 8:06
    and we went through the basic terminology,
  • 8:08
    which is really Git terminology.
  • 8:11
    And then we took a little look at the actual dashboard that you get,
  • 8:14
    which we'll be looking at in more detail in another lesson.

Pantheon Branching and Multidev


By default Pantheon provides you with three environments: Dev, Test, and Live. A lot of work can happen in Dev though, and it would be really great to be able to manage all the different branches of work that may be happening simultaneously. Pantheon's Multidev feature will do this for you. You can always create as many branches as you need for development in Git, but Multidev takes that a step further by actually providing an entire duplicate environment for each of your branches. This way you can see exactly what the site looks like with those code changes before you actually merge everything into your main Dev environment. In this presentation we'll explain the benefits that Multidev gives you and walk through the terminology you'll encounter. The Multidev process and terminology is based on Git workflows so you'll be getting a short Git overview as well.

Here is a quick list of the terms and workflow we'll be reviewing:

  • environment: Independent infrastructure for a site, including code, DB, and files.
  • fork: To divide in branches, copying source code to start independent development. Pantheon also copies content (files and database) when forking. commit: Record snapshot to history.
  • branch: Movable pointer to a set of commits, allowing independent development and history.
  • master: Name of default branch; deployed to Pantheon Dev, Test and Live environments.
  • merge: Combine contents of a branch into another, like a bug fix branch into master.

Sponsored by Pantheon

Log in or sign up to download companion files.
Additional resources: