With merging only going into environment branches and bugs and features being independent branches, we really need one stable branch for all branches. Given the convention of using a "master" branch, this branch would be the source for the build process. This follows fairly well the source code control flows we detailed earlier.
Feature and bug branches can still be used, they would simply be branches from the master (maybe via development branch which should also be branch off of the master) and any changes that need to be deployed would first be merged into the master.
Promotion
One of the caveats of the build-per-environment strategy is that your source code control ends up being read-only branches that contain the code that may be currently deployed to the corresponding environment. Typically you'd only merge into the environment branch for the sole purpose of performing a deployment, but there's no way to guarantee that. So, as some astute readers may have deduced, this ends up being no different than having a main (master) branch and tagging . By going down the tagging route, you invariably end up on the promotion strategy of managing deployments with the addition of many branches to managed, with little value.
To a certain degree, the strategy you go with is affected by your deployment tools. Visual Studio and Release Management have typically supported the promotion strategy so it's easy to get going with this strategy. Just because the workflow in Release Management assumes "promotion" from environment to environment, it still allows the execution of generic tasks at each stage. So, a build-per-environment strategy could still be performed with Release Management.
Environments
To some degree, the choice of deployment environment follows Conway's Law. For sufficiently complex systems: if you have a team of developers, you'll likely find great value in a Development environment; if you have a discernable Quality Assurance role, you'll likely find great value in a Testing environment; and if you perform User Acceptance testing, you'll likely find great value in a User Acceptance environment.
Needless to say, knowing the value of each type of environment when planning your deployment environments and applying them to the needs of your team goes a long way toward implementing environments that add great value (as well as not implementing those that do not provide much value).
The quantity and types of environments you choose to create and deploy not only depend on the roles you may have that depend on them, but also the degree to which you want those roles to perform their tasks independently. You could, of course, have one non-production environment that a version of the system can be deployed to that is shared amongst all the roles. While developers are designing and developing, they use the environment; while testers test, they use the environment; while integration is being tested, the environment is used for that; while users perform user acceptance, then use the environment. To some degree this may seem logical; after all, developers produce software that testers test and, once tested, users use. Unfortunately, we've learned from Agile (or prior to Agile) that Waterfall development is a myth and software is best developed iteratively. This means that it's quite likely that developers are on to new work while testers are testing and testers are testing new systems while user acceptance is being performed. So, it's highly unlikely that a single non-production environment will be sufficient. Let's have a look at the common environments.
156
Local
Although I detail a Local environment here, there really isn't a local environment, per se. I say that because it's not an environment that someone sets out to build for a particular system. It's an individual developer's computer and any external resources that they have access to. So, on a team, there are many local, disparate, environments.
The disparity of local environments from developer to developer really underscores the need for the environments we're about to describe.
With the differences in these Local environments, if one developer encounters a problem, it's indeterminate that it can't be due to the haphazard setup of that environment. Comparing it to another developer's environment may or may not shed some light on the problem. Inherently comparing execution in two local environments is still indeterminate. It's a recommended practice to use non-local, independent, environments for various levels of testing.
Experimental
The creation and setup of any one environment for any system really depends on knowing a fair amount of information about a system. For example, an environment requires one or more computers, each computer having certain resources pertaining to RAM, CPU, and disk. Network connections between computers may need specific configuration involving speed, firewall, etc. Not to mention all the external resources and their types (databases, queues, caches, etc.)
All of these elements of an environment (or environments) require they be known in order for an environment to be built. This leaves a bit of a dilemma—how can we accurately discover what environmental requirements our system has without an environment?
This is where an experimental environment comes in. This environment, sometimes called a sandbox , is an environment with access to various resources and the ability to be configured/reconfigured rapidly. This environment allows developers to deploy, redeploy, configure, and reconfigure, until they can prove, through a series of tests, that a particular environmental configuration suits the system that needs to be deployed.
Development
Sometimes a Development environment is considered the same way as the local environment. For simple systems this may be sufficient. A local environment could have local resources like multiple local running services, local database, local queues, etc.
In more complex systems, or systems where the dependent resources simply can't exist on local, developer computers, a development environment is a necessity.
A development environment allows developers to deploy software to a system that has some of the same attributes of a production environment (multiple servers, remote queues, remote databases, etc.). The environment can be controlled by developers at a reasonably low level, allowing them to reconfigure the environment to help debug issues without affecting other environments (like testing and testers, or even worse production and users). Developers need to be free to install debugging tools to help them find the root causes of issues (that might not have been discovered in a Development environment).
Integration
An optional environment is an Integration environment. For the most part, if a team has a Development environment, they probably have all the resources they need to do comprehensive integration testing.