On March 22nd I gave a presentation to ASU's Software Developers Association which I called "What My Professors Didn't Teach Me - Developer Skills: What They Are, Why They're Important and What You Should Know About Them". The presentation provided an overview on seven different "developer skills" that I believe are necessary to succeed as a professional software developer. I define "developer skills" as those aptitudes between the "hard" technical skills of programming / hacking and the "soft" interpersonal skills of teamwork and communication. They are the things that a developer needs to know to succeed at his job outside of actually building software.
Over the next several weeks I will be writing a post on each of these proficiencies; each post will describe what the developer skill is, why I consider it to be necessary knowledge for the workplace, and what specific things you should learn. I plan to have links to tutorials or other websites that you can use to follow up.
The posts will be as follows:
Part 0: Introduction
Part 1: Version Control
Part 2: Ticketing Software
Part 3: Multi-Branch Development Workflow
Part 4: Libraries and Package Managers
Part 5: Working with Remote Computers
Part 6: Communication Between Software
Part 7: Securing Your Communication
The idea of a multi-branch development workflow is straightforward and simple, so much so that it may actually appear complicated. Part of the reason that this topic can be difficult to wrap your head around is because there are so many different ways of doing it. I'll do my best to try to cut through the complexity and clear things up.
One way to describe what this topic is is to describe what it isn't. Let's look at the two previous posts. Part 1 - Version Control focuses on tracking (that is, keeping a history) of changes made to your code, and moving those changes from one version control branch to another (like from your local branch to a remote branch in a repository). Part 2 - Ticketing Software discusses keeping a history of functional (business) requirements in the form of tickets, and keeping track of the progress of each ticket as it moves from the design stage, then to the development stage, then to the testing stage, and so on.
With both of these systems, there are two clear functionalities: one that tracks history, and one that moves an item from one place or state to another. I find it helpful to think of moving the code and changing the ticket's state as taking a step in the journey to completing a unit of work.
In the real world of development, it turns out that your code really does take a physical journey from "in development" to "live on the web" (or "in the master build", if we're talking desktop software). This physical journey is what I call the "multi-branch development workflow".
Image Credit: godaddy.com
What Is This?
Think back to your time in school. When you did a programming project, you would most likely create the project on your local computer, develop it over time, fix it when you break it, and ultimately complete it. Then you'd zip it up and send it to your professor. During the entire process, you have a single copy of the code. This works for school because the only thing you care about is getting working code to your professor by the deadline. In the meantime, it doesn't matter if the code is broken, or ugly, or doesn't have all the features required.
This is not the case for development in the real world. If you're working on adding new features to the website, it very much does matter if your changes take the site down while you develop, or makes the site look ugly, or otherwise break things in some way before your changes are complete. All site owners strive for the best uptime possible, and one of the worst things you can do is harm that. In fact, this is so important, that virtually all professional development shops maintain a second, isolated copy of the codebase, solely for you to develop in. This way, you can develop in the "development branch", while the "production branch" is left alone to power the site.
You never want your users to see this - so don't develop in the Production branch! Image Credit
Here we see the most basic form of a "multi-branch development workflow". The idea is simple: have multiple copies of your codebase, each one serving a different purpose. The Dev branch is for development - if you break it, we don't care. The Prod branch is what powers our live site (or is used for our nightly build, etc.) - it must never be broken, so only change it when we know our changes are working as desired. This is what we meant earlier by your code taking a "physical journey" - as your development moves forward and your new feature becomes usable, it is actually moved from one branch to another.
This two-branch model is the simplest multi-branch development workflow you can get. There are others that introduce new branches, each with their own purpose, each designed to physically separate the various concerns of the software development lifecycle. For example, consider adding a third branch, QA:
Image Credit: http://www.softwaretestinghelp.com/
Adding the QA branch gives us a dedicated place where code can be tested, without having to worry about your test code being affected by the activities of another developer. As before, we don't want to test code in Production - nothing should enter Production until it has been fully tested out.
Here's a third, more advanced multi-branch workflow:
This workflow has multiple "feature" Dev branches that allow you to develop in isolation from other developers; a "Developer Pro QA" branch where your code is merged in with other people's changes; two separate testing branches for two different types of testing; and finally, three Production boxes, each for its own use.
What these examples show is that there are many different ways to design a multi-branch dev workflow. There are also many ways to determine when and how your code should move between branches - what permissions do you need to migrate? Can you do so at any time, or do you need to follow a migration schedule? All of these things are something that your team must work out themselves.
Why Is This Important?
I've discussed above why using a multi-branch dev workflow is important for a business - but why is it important that you know how to use one? First and foremost, because it's highly likely that you will be using one on the job - so just like with previous developer skills, the more you know before you start, the sooner you'll be able to start doing real work.
This being said, it's often the case that your business won't be using this workflow, or at least won't be using it effectively. In those cases, it's crucial for you, as a developer, to know the subject well enough to propose changes to the workflow and help implement those changes. You'll want to make these changes, because the quality of your multi-branch workflow will, to a large degree, determine your quality of life at work.
The multi-branch workflow separates concerns. When set up right, it allows you to focus solely on your own work - development - and leave other jobs to be performed in their own environments. Among other things, this means that:
- Other employees outside of your role will not be interfering with your work
- You won't interfere with the work of other roles - just as important a consideration
- Your changes or mistakes won't cascade into larger problems - as discussed above, you won't break Production.
- You'll be able to push your work out faster, since you'll have your own environment to work in.
- You'll be able to respond to emergencies faster
To summarize, the better design your system has, the less time you'll have to spend doing things other than developing. That alone is a good enough reason for you to know a decent amount about this topic - it will allow you to offer improvements to the implementation at your workplace, if it falls short in some areas.
Things You Should Know
I recommend knowing two types of things for multi-branch dev workflow: the general questions, and some specific implementations.
The general questions are a set of questions that you should ask about any multi-branch workflow. Knowing these questions - and how they should be answered - will allow you to evaluate your workflow.
The questions include (this is not exhaustive):
- How will code flow from the development branch to the master branch?
- How do you handle emergencies (e.g. if something breaks Prod?) Do you roll back master, hotfix it, etc.?
- When are migrations done? Are they on a time based schedule (e.g. a release every two weeks) or a feature based schedule?
Knowing what questions to ask will definitely help you learn how your multi-branch system works, and give you some ideas on how it can be improved.
The major area I'd recommend knowing is: know some of the major workflow designs. I'll mention two here.
The first is "git flow". This is the classic three (sometimes four) branch model of Dev, QA, and Prod. A full definition of git flow describes how you handle edge cases or emergencies like hotfixes.
Image Credit: joefleming.net
The second major workflow is called "github flow", and it uses a much simpler design, one with only two branches - a feature branch and a master branch. This is called "github flow" because it very closely mirrors Github's Pull Request design.
Image Credit: theodi.github.io
With that, we wrap up the first three posts on "codebase management technology." The remaining four posts will be focused more on general developer awareness of certain topics - primarily centered around communication between two discrete units. Before we get to that, though, we're going to be talking about a certain tool that is used very heavily in the real world, but not in school - package managers. Stay tuned!