Before we dive into process, there’s a couple of logistical details we need to discuss. If you’ve already put these in place, then you can safely pass on by to the planning portion of this section, but if you don’t have this foundation in place, you’ll want to make sure and address it first because without these two pieces, the rest of the process will be virtually impossible.

If you want to ship high quality software, you’re going to need version control, also known as source control, paired with release management. Whether you’re a solo developer or a team of thousands, you can’t have a good process without using source control and a reliable way to release finished code. The former enables you to manage your code, and the latter helps you get that code where it needs to be.

These two tools will weave in and out of virtually every aspect of software delivery from here on out. While the full extent of each of these is outside the scope of these lessons, we’ve put together a brief overview to get you headed in the right direction.

Version Control

Version control, or SCM is integral to creating software. While many of its benefits kick in with larger teams, even a solo developer can benefit from running source control. It enables you to easily recover from mistakes, review past changes, collaborate with other developers, backup your code, and automate code-related tasks.

Your first choice would be which source control platform is right for you and your team. Here’s a short list of some of the more popular options:

• Git
• Mercurial
• Subversion

While source control is outside the scope of what we’re discussing, there are some great tutorials available. GitHub has created Try Git, Beanstalk has a variety of guides for using Git, the makers of Tower offer Learn Git, and Joel Spolsky has created Hg Init to help you get started with Mercurial.

Once you’ve decided on a source control platform, you would then need a place to store your code. You could opt to self-host your source control, but there are a handful of applications out there available to make these easier for you depending on which platform you choose. And if you’re new to source control, I strongly suggest using a hosted provider so you can focus on learning the tool rather than managing it. Some of the more popular hosted source control providers are:

• Beanstalk
• BitBucket
• GitHub

There are quite a few benefits of going with a hosted source control provider, but the biggest benefit is that they’re generally easier to connect with your other tools. As you’ll quickly find out, source control will be at the heart of your process, and the easier it is for you to connect it with your other tools, the more productive you’ll be.

Release Management

Throughout the software development process, your code will go through cycles of development, testing, and fixing. Depending on your team, technology, platform, and other variables, you’ll likely have several environments that you use to manage your application. ¹ In order to effectively test and release software, it’s imperative to have a simple and reliable release process for getting your code onto your various environments.

Your options for release management are literally endless. You could write your own scripts entirely from scratch or lean on tools like Capistrano, Mina, Fabric, or dploy. Of course, those are just the tip of the iceberg, but there’s likely an equivalent tool available for your platform.

Flexibility & Recovery

Your release process will be the bottleneck in your ability to ship software.

Your release process will be the bottleneck in your ability to ship software. If it’s difficult to release code, you won’t release as frequently, and you may end up facing difficult choices where you need to release an update but fear disrupting your customers or acting to quickly. With a good release process, you should be incredibly confident releasing updates with no interruption to your customers. The best rule of thumb to know if your release process is good is whether you get anxious when releasing updates. That anxiety is often a symptom of a lack of confidence in your processes, and you should probably spend some time streamlining your releases.

Beyond the necessary side of getting your code where it needs to be, one of the biggest benefits of good release management is the ability to rollback in the event of an emergency. No matter how finely tuned your development and release process is, you’ll occasionally have hiccups in production. When this happens, you’ll want to be able to easily rollback to your previously released codebase without breaking anything. This way, you’re not forced to rush an ill-considered fix out the door. Instead, you just rollback so that you can resolve the issue without affecting customers and then release again when it’s ready.

Environments

With web applications, you’ll need at least two environments: development and production. If you have a large team or more complex application, you might have several environments including integration, QA, or staging in addition to development and production. These environments are the targets of release management. As your quality assurance process matures, managing releases to these different environments will become increasingly critical for your productivity.

Development

Every developer has their own local development environment that generally won't be accessible outside of their own machine. You won't ever “release” to development per se, but you will want to be able to easily bootstrap your development environment so that team members can quickly set up a new computer.

Integration

The integration environment can be a shared semi-public system, but more often than not, this would be handled by an automated process called “continuous integration” that automatically tests new code by developers to make sure that nothing is broken. Similar to your development environment, you wouldn't release to your integration environment. Instead, it just monitors your source control system for updates and automatically runs your automated test suite.

Quality Assurance (QA)

If your process is involved enough, the quality assurance environment is an internally available environment that provides a consistent and stable environment for your testers to locate and reproduce issues.

Staging

The major goal for a staging server is to reproduce production as closely as possible in order to minimize any surprises from production-level configuration differences. In some cases for smaller teams, you may be able to combine QA and staging into a single environment.

Production

Production is the final resting place where you make your code available to everyone. Due to the need for scaling and reliability, production will often be more complicated than your other environments.

Controlling and coordinating which version of your software is in each environment is important for reliable testing and reproduction of issues. For instance, if someone on your QA team is reporting a problem, but your developer is unable to reproduce the problem, it’s entirely possible, or even likely, that they’re both looking at different versions of the codebase. So you want to make sure that everyone is always on the same page about what version is being reviewed at any given time.

Continuous Deployment

Continuous deployment is one of the most advanced setups for team that have quality and process locked down. In these situations, releases are set up to happen automatically if new code successfully passes all of the automated tests. In order to do this, your team has to have an incredibly level of confidence that new code is tested and working. In this scenario, whenever someone adds new code, it will be run through all of your automated tests and, assuming they pass, put the code into production.

What’s next?

Now that we’ve laid the groundwork for the foundational tools and processes, we can see how it all comes together in the context of a real project. First we’ll discuss planning to see how issue tracking can help prevent problems before they become costly implementation mistakes. But before we do that, let’s take a look at the larger context of software delivery organized into four phases. Planning, or organizing ideas and goals. Creating, which is primarily design and development. Reviewing, or all of the processes around quality assurance and testing. And finally, listening, where your code is live, and you have a variety of monitors and tools in place to alert you to any problems.

This is meant to be a technology-agnostic high level overview of some of the key facets of modern iterative software development. These cycles or iterations could each last a single week or multiple weeks. It depends entirely on what works for your team.