This series of brief articles is made up of a few things I’ve learned over the last few years of running projects based in the area in which we (assuming you’re reading this coming from the same part of the industry I do 🙂) work.

If you’re just stumbling across this, the series is covering some factors that are important for a project:

  1. There should be no “design by committee.“
  2. No one else other that the core development team should be able to provision development, staging, and production.
  3. No one should be able to write to production but the development team (and even then, there should be a deployment process).

I don’t really like making hard and fast rules like this namely because things change over time either by necessity or by more experience. This is why I like “guidelines.”

But at the time of this writing, these are the things I see playing out.

Provisioning Environments

Over the last few years, we’ve made a lot of progress in how quickly we can provision our systems so that they all mirror one another (or generally so). This includes our development boxes, how our local machines mirror staging, and how staging mirrors production.

Provisioning Environments: Preparing The Workstations

Provisioning a new environment, more or less. Roll with it.

That is if it “works on my machine” should actually be true. Not an excuse for not being able to reproduce a bug.

And when it is true, it’s likely to be true on others’ machines, on staging, and production. And this is nice, right? I mean, we spin up our boxes, deploy our scripts, or do what we do and then we have the setup we need.

So what’s it mean to go about provisioning environments? It depends on which environment to which you’re referring.

What’s This Really Look Like?

If you’re working in WordPress, which I assume you are if you’re reading this, then it assumes you’re running a web server, a database, and PHP at a minimum.

A development environment may look like the following:

  • Apache of Nginx,
  • MySQL which is the most common,
  • At least PHP 5.2.4 (with PHP 7.1 recommended),
  • Or something comparable.

You may also be using something like Laravel Valet or something like VVV. It all depends on the nature of your work.

Furthermore, depending on the nature of your business, you may have an IDE that’s assigned to you along with various configuration files to enforce certain rules.

And the Rest of the Environments?

As usual:

  • development refers to the setup on your local machine,
  • staging refers to the area in which you and the stakeholders and can test,
  • and production is where the application resides.

But this also looks different depending on where you work, how your work is organized, and so on. It’s not so much about how it’s used – it’s about that it’s used.

Staging

This will usually be provisioned on a server (or group of servers depending on the size of the project) to which you can deploy your latest code for testing. It can include partial functionality, test data, and only a subset of information from the production (if you opt to pull that information, namely the database, from the production environment).

This gives you and the other stakeholders the ability to review what’s going out and how it will function in production without actually having to worry about destroying anything sensitive.

The code is commonly deployed from a branch, usually master, from your Git repository (if that’s what you’re using). And tools such as DeployBot, CircleCI, Travis CI, GrumPHP, Behat, etc. are also used to both evaluate the code quality, run any automated testing, and then finally deploy the code.

In the end, each environment will be provisioned in a way that they can be quickly mirrored across local machines, the staging servers, and the production servers. Further, it should be easy to push and pull data between them to make working with the data easy.

Production

Finally, production is all about the actual functioning project; This means that it has the server, application, and database running in conjunction with one another and is being used by users.

This also means that the code is in a stable place. There are likely logging mechanisms in place that will notify the development team of any problems. No changing of code should occur in this environment without having it pass QA or staging first.

And the Processes in Place?

Okay, so let’s say you’re working with a traditional setup, for lack of a better term, where all of your deploys are done so via S/FTP into a production (or even staging) environment. This way, users can pull down files, make the changes, and push them back up.

That’s no good.

This means anyone with the credentials can log in, make the changes and bypass source control, continuous integration, quality assurance tools, and so on, perform whatever changes they want.

It undermines the entire processes put into place. Not only does this bypass standard procedure (which is in place for a reason, of course), but it ends up breaking the code that a developer or team of developers have on their machines primarily because what’s in production is no longer in sync with the code’s repository.

Furthermore, this code could be spread across branches that are yet to be merged or deployed. This leaves us with a variety of situations in which developers and customers have broken some part of the build process and thus the entire project.

When it comes time to check production, it’s out of sync with development and staging, and no one knows why. When it comes time to deploy, the changes are overwritten, and those responsible have lost what they thought they were going to see.

What’s a Team To Do?

I don’t know if there’s one right answer to this, but the longer I work in this industry, the more I believe that the firm – or firms – responsible for building the solution for the client should have control over the process from end-to-end.

  • Designers are responsible for managing their areas of creating the concepts, mocks, creating demo templates, and soliciting feedback,
  • Project Managers are responsible for communicating with departments,
  • Developers are responsible for implementing the solution and tying together the designers’ work with the functional back-end,
  • The client is responsible for reviewing changes, providing feedback, and providing any other information necessary to complete the task.

This means that when it comes to setting up the domain, the hosting, the environments, the version control, the build process, and continuous integration, and everything else that I’ve neglected to mention falls squarely on the development team.

Provisioning Environments: Stay in Your Lane

Stay in the trenches, stay on target (but be mindful of those around you).

Simply put, these are not the responsibilities of the client nor should they be. Boundaries of responsibility should be set, maintained, and respected across all teams –  not just developers and clients or clients and designers or designers and developers and so on.

What’s Next?

In the next post, I’ll talk about the responsibilities that developers (and other stakeholders) have in maintaining environments for the code.

That is, who should be responsible for what and who has access to read and write what data and how it can ultimately impact the result of the project.