I've worked as a DevOps Engineer for a long time now, since before DevOps was officially a thing.

I love it, working with developers to implement their sites on blazing fast servers and handling client questions, building out continuous integration and delivery solutions that help automate and test what needs to be done.

But, now and then, I get people emailing or calling or messaging from other sources.

They want DevOps engineers, desperately, but they don't have a remote workplace period. They want their DevOps on site.

And want to know a funny thing?

The servers aren't even on site!

That's right, usually they're hosted on AWS, or Digital Ocean or Rackspace, or Linode or some other place.

So what exactly is the point of being on site?

One particular company, wanted someone to re-vamp their chef cookbooks into ansible playbooks.

Which is fine, but, how is that an on site project? And while one or two days on site would be fine, 4 days a week on site?

I love DevOps because it's remote, you have your tools that you use:

email
slack
phone for voice or sms
GitHub Issues
hangouts or zoom (or even slack again)

These put you within reach of anyone 24 / 7.

Then with tools like ansible, terraform, chef or puppet, you can manage your entire server structure.

But, what about deployments? One company used to only perform deployments on site (again, servers not actually on site).

That is what continuous integration and continuous deployment means.

If you've got your work flow set up properly, then you can code your current tasks, entire teams can code a current sprint for instance, push to their proper branches, then schedule PRs that are then reviewed by other team members and also tested using tools such as:

Finally as branches are merged, then you'd be sending deployments to the proper places for example:

pushing code to the development branch would send a deployment to your dev site
pushing code to the staging branch would send a deployment to your staging site.
pushing code to the master branch would send a deployment to your production site.

Now these three branches should be protected, I love how GitHub lets you make protected branches that require each PR to be reviewed by another team member and also for tests to pass before they can be merged.

Then once the client[^1] has tested dev and staging you can push to master. Generally, you'd schedule a push to your production site.

But does that really involve being on site?

Of course not, if the code flow has been set up properly in the first place then by the time you push to production, nothing has changed.

And with the advent of Docker, this is even better, as your code is wrapped around an environment that never changes from developer's machine, to dev site, to staging to production.

And yes, there is a matter of access, but using handy tools like a company VPN, server keys and jumphosts, then you can lock down who can access what and when and from where.

So to finish this off, I just want to put this out there:

If you're looking for on site DevOps, then you are doing something wrong, and I've love to talk to you about your reasoning for why you think you need DevOps on site and maybe even help you revamp that thinking.

[^1]: or another team member responsible for QA.

Do you like my content?

Sponsor Me On Github