Devops and Infrastructure for the Solo Dev
Tags: continuousintegrati, devops, codereview, solodevs
Published: 2019-01-28 20:49:33

---
title: Devops and Infrastructure for the Solo Dev
published: true
tags: continuous-integrati,devops,code-review,solo-devs
canonical_url: https://hackernoon.com/devops-and-infrastructure-for-the-solo-dev-47c1f572aeda
---

Being solo doesn’t mean your infrastructure and operations has to suck. Sadly, in teams of one (and small teams in general), people being physically or emotionally close (eg friends in life, business partners) can be a great excuse to ignore this important part of your day-to-day.

You could find a ton of reasons to invest in a DevOps infrastructure, but the two most important for me are:

![](https://cdn-images-1.medium.com/max/896/1*LiO01tPqoqTGunPqAXInQA.jpeg)<figcaption>A solo dev</figcaption>

### It will save your arse in the long run

So you are having a demo tomorrow to your only client or to a very significant stakeholder in your company.

Are you sure it is going to run as expected? Are the [automated tests](https://perigk.github.io/posts/self-testing-for-solo-devs/) running successfully all the time, during the preparation? Is the deployment process automated? Do you have a “click it and leave it” level of trust to your deployment tools?

If you are doing all those stuff manually, how do you know that the expected stress before the big demo, will not sabotage you? Make a system to not allow this. Devops!!

### It will help your team scale efficiently

You might be a lone wolf now, but if things go well, you won’t be a lone wolf forever. Ultimately, you will pair with other wolfs (hire colleagues, get more team members) and get more quarries during the hunt (scale the company).

You want to make this easy, but if all wolfs follow a “kinda process” you will get “kinda results”. And this is not true only for operations but for the development part as well.

Let’s see some things, that I believe will be helpful to do from day one.

### Version control and flow code flow strategy

Believe it or not, not all people appreciate the powers of a version control system (VCS), but it is really important. After all, Joel has it as the very first question in his [beknown test](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/). That’s because it is the most basic and most important thing in the infrastructure.

But having a VCS is not enough. You need to have a code flow and branching strategy, otherwise, everyone will be pushing to master, which is of no use. You can read more about that [here](https://www.creativebloq.com/web-design/choose-right-git-branching-strategy-121518344).

### An issue tracking process

For starters, even the basic, “ToDo-Doing-Done” workflow from trello will do, but investing in a more detailed workflow will pay off when the tasks increase in size and the parallel streams of work will become tenfold in size.

You probably won’t need it, if you don’t intend to have a life for the next X years and only remember the status of each ticket.

You can use [Jira’s](https://www.atlassian.com/blog/jira-software/building-workflow-awesome) or [Trello’s](https://blog.trello.com/what-is-a-workflow-and-why-do-you-need-it) blog for inspiration and ideas.

### Some kind of automated testing

I don’t care if you preferred solution will be a clicking-robot, which will be paid in batteries or the best unit test suite with 120% coverage. Unit testing can be [easier than ever](https://perigk.github.io/posts/a-comprehensive-guide-to-unit-testing/) and there are other kinds of testing like [BDD-testing](https://cucumber.io/) which an increasing number of people find it more natural. Pick one, and try to achieve a decent and always increasing coverage.

Focus on having more than 85% coverage to your keystone-areas, as much as possible.

### Code review

I have written some tips on doing [self-reviews](https://perigk.github.io/posts/code-review-for-the-solo-dev/) but given we are speaking about infrastructure, this is a good time to focus some of your energy to set up an automated code review a solution like [Sonar](https://www.sonarsource.com/) or [Codacy](https://www.codacy.com/).

They can’t replace human intuition, but they are at least very helpful flag raisers when something smells big time. They are usually integrated with the CI/CD flow. Speaking of which…

### CI/CD

Having a CI/CD solution deployed, with a minimal, is ridiculously easy today. For example, gitlab offers [out-of-the-box CI/CD](https://docs.gitlab.com/ee/ci/quick_start/) and you can find tons of examples in open source repositories, which can be adjusted to your needs, in order to achieve a minimal setup.

Every time a build event is triggered(usually a change in the master branch of your VCS) the CI/CD system is following a process which involves steps like compiling your project, running the tests and deploying to a remote server. This is how you ensure a minimum of quality and lets you have a better sleep the night before the big demo. :)

I get it, being solo and setting up all those stuff can be overwhelming. Apart from the basics though, you can set up a few other things that will leverage your work even more. But you can probably survive and scale (a bit) without them.

### IaC, virtualization, and similar tools

If you have ever seen people deploying various docker images to a number of cloud servers or being able to migrate to another cloud provider in a glimpse, you know what Infrastructure as Code (IaC) mean and how beneficial it is. Pure magic. If you don’t [here](https://www.linuxnix.com/terraform-introduction/) is a nice article about Terraform, a beknown tool of this category.

### Monitoring and alerting tools

Do you love waking up, in the middle of the night, because someone is trying to DDoS your web application and a monitoring tool, gave you an [automated call](http://www.linuxscrew.com/2011/09/13/nagios-notification-by-phone-call/)? Yeah, me too #sarcasm

Still, this is something that will repay you **with interest** , especially if your software is being used by clients who need to be online 24/7 (eg banks).

If you want a hint to get started, have a look at one of [Nagios](https://www.nagios.org/), [Rollbar](https://rollbar.com/), [Sentry](https://sentry.io/welcome/) or [Pingdom](https://www.pingdom.com/).

Thank you for reading this article. If you are on a solo journey, don’t forget to read my [other](https://perigk.github.io/posts/code-review-for-the-solo-dev/) [two](https://perigk.github.io/posts/self-testing-for-solo-devs/) articles on the field.

If you want to comment on anything, I would love to hear your feedback.

_Originally published at_ [_perigk.github.com_](http://perigk.github.com)

* * *