In the past few articles, I’ve talked about a couple of things (saved for actually writing to production) that help to run a successful project:

  1. The dangers in “design by committee,”
  2. Considerations for provisioning an environment.

The last thing I want to address the learning I’ve experienced thus far is about maintaining the proverbial keys to the kingdom of writing to production and why that matters.

Writing To Production

The idea of writing to production may seem like the most dogmatic guardrail of those mentioned because it’s usually okay for those who are building the solution and they know the ins-and-outs of how it’s working.

The other stakeholders likely don’t (but if they do and the development team is okay with the others using version control to handle this, then go for it).

Writing To Production: Who has permission to access the live site.

Who has permission to administer this stuff, really?

Remember, though, as mentioned earlier in this series, the way in which we’re deploying our projects has changed now such that we often have continuous deployment and continuous integration.

And often, these services are hooked into a source code repository, such as GitHub, and a messaging system (which, in turn, may be hooked up to Slack which I find useful).

So that people on the team are aware of what’s been deployed and when and they know how to get the code (which is from the repository, not from downloading it via S/FTP) if needed.

When a hotfix is needed, there should still be a procedure in place. Perhaps someone is on call, and there is a process by which branching, merging, tagging, and semantic versioning is used.

Regardless, it’s not so much about how the process works; it’s that it’s in place and that it’s followed.

Of course, these things aren’t put in place to make development more complicated (though I understand how it may seem that way). It’s on the contrary. It’s for a variety of reasons:

  • to keep continuous deployment, y’know, continuous,
  • to have integrated tests,
  • to continually measure coding standards or code quality,
  • to prevent cowboy coding,
  • and more.

It’s not so much about keeping other people out, but if it’s the developers’ responsibility for pushing code, then should anyone else really have write access to the server?

And that’s the bottom line: If you’re working on a team where the processes you have in place can completely undermine the work that you’re doing, what’s the purpose of the process, anyway?

Because at any moment, someone else can come along and this disregard everything you’ve done. You’re then, at the very least:

  • stuck with having to pull their changes likely via S/FTP,
  • compare it using a diff tool against a branch on which someone is working,
  • implement the changes (let along find out why they were made),
  • and then get back to work on the requirements.

It sounds hectic when you put it like that, but that’s exactly what happens.

The Takeaway

So what’s the whole purpose of the last few posts? If I had to summarize it as succinctly as possible its:

When it comes to a project, know your responsibilities and do not step outside of them. Otherwise, you risk derailing the entire thing.

This goes for developers, designers, clients, marketers, project managers, etc. How the roles are designated, don’t know much matter (I mean, it’s usually clear who should be who in the roles above) but I mean in terms of who the actual point person is – the project owner – for the entire project.

Writing To Production: Don't be this guy.

Don’t be like this.

And depending on how all of the above goes, the project can be a relatively straightforward set of day-to-day work.

As much as possible, don’t we want to enjoy what we’re doing