Starting My Own DevOps Friendly Web Design Agency

OK, so I’m on my own and I am building an agency. My imaginary agency is called JamShack. I have 3 clients that want to come on board. One is an old friend, one is a referral from that friend, and the third was someone I met at a networking event while I was trashed. Everyone thinks I am awesome. They are all WordPress sites. 2 of the 3 were left to rot on servers and are running a version of WP that is so old, that I have to run an unsupported version of PHP so I can spool them up to grab the content.

The previously mentioned WordPress sites are only updated occasionally, with the exception of site number 3. The person, who happens to be a lady, I met at the networking event is a blogger that writes daily about in a sustainable culture niche. She will be doing her own daily posting, but needs me to do the technical SEO, hosting and all the behind the scenes stuff.

Things YOU Need To Start A DevOps Friendly Web Design Agency

In order to be a full service agency, I need a variety of things. I am going to focus on the basics of the technical enterprise.

• A place to host my own website
• A place to store all my source code
• Something to facilitate automation
• Process and procedures so I can scale right away
• Laptop or desktop computer
• Hosted email
• Some project management tool
• Place to keep customer secrets (usernames, passwords, API keys, et. al.)

What’s nice about this day and age is most of these things are available for free. I am going to be using my laptop to do most of my development but I will eventually be hiring some developers to take this task off my plate. I will probably get one from Upwork, then maybe the other two I bring in as sub contractors. I don’t have payroll money yet, but I still need to be able to work with other developers if I have a hope of making this sustainable.

I grab a fat bag of Death Wish Coffee and start building the business. I sign up for the following services:

• Domain - I buy my domain because I need it to set up email (you may already have this)
• Hosted Email - I am partial to Office 365 because I come from the managed IT world. Fight me. Google is fine, but don’t try to host your own email, that is a huge mess. Google or Microsoft will give you a central place to keep documents too. Many hosted email platforms these days also come with some cloud storage space, which will be important for non-development related things, as well as dev related stuff.
• CloudFlare - I need this to put in front of all the websites I will be managing. I will cover this in a few moments.
• Netlify - This is a hosting outfit that offers static website hosting for free depending on how much you need in the way of features. The thing I love about it is that I can hook it right into my GitHub repository, set it to monitor my ‘master’ branch and it will automatically deploy changes that I merge into said branch on the fly.
• GitHub - This is where I will centrally collaborate on code that I will deploy using Netlify.
• Static Site Generator - Downloaded and installed Hugo on my computer.
• Docker - No development workflow these days is complete without having something like Docker. I need it for spinning up sites and tools locally without having to install 8 different versions of MySQL, Apache and PHP.

Now that I have my GitHub profile and initial repository set up, I have a place to commit code for my agency website, and it is also where I will commit and collaborate with customers' code as well. I have my free plan on Netlify all set up so I can jamshack.whatever. I got my email all set up, my online workspace for doing things like building proposals and storing checklists. I have my nameservers for jamstack.whatever pointing at CloudFlare.

Setting Up Your Agency DevOps Process

Once you have the nuts and bolts sorted out, you need to have a process for everything, because at any moment, you could be working with multiple developers. There are 3 keys to business - people, process and product. People execute the process that makes the product, for the people.

I make checklists in my cloud drive (OneDrive, or Google Drive using Google Docs) for the following critical processes:

• Customer Intake - you should have a process for taking customers in and getting a copy of their code do you can start developing right away. You should standardize this process and follow it to the letter every time. Eventually you will find ways to automate parts of this, or the entire thing, but it all starts with a checklist. The list should have:
  • Getting their code
  • Collecting DNS information
  • Any passwords you need
  • Contact people for your project
  • Setting them up in your Quickbooks/Freshbooks/Whatever you bill them with
• Development Workflow - This is a guide with a drawing of what the development pipeline looks like, how to handle branching in Git, and what generally happens happens when within the development process. This will be important for me to share with the customers so I can show them how my process works, but it is most important for when I get other developers. My Development workflow summarized will be as such:
  • Ingest customer code (if it exists)
  • Sign up for GitHub for the client if they don’t already have one, using an email address that belongs to the client (I have run into so many cases where code custody is a problem, so it is important that my clients own the code.
  • Create repository for customer website
  • Add my GitHub as a collaborator
  • Set Up Branching in Source Control:
    • Master branch in Git is where all the production code runs from
    • Develop branch is where I do development stuff
    • Stage branch is where I merge commits from Development to make sure there are no errors in the deployment process
  • Develop and test on my local machine, when validated, commit to ‘develop’ branch, then after I complete a set of development tasks, I merge them into stage to test “at the edge,” and so the client can validate changes using a browser accessible URL.
• Code/Change Deployment - The code you work on eventually needs to go some place where it will run and people will see the site. At first, a simple checklist for this will do, but this will be something that you will want to automate down the road. Since my 3 clients will be using Hugo static site generators (Their use cases are simple), and I will be using it myself, Netlify will handle the automated deployment of my sites. I will make a note of this in my deployment checklist, but there will still be some unique workflows for these customers since their use cases are different.
• Business Process Checklists - Since I will also be handling some light duty social media for my clients, I will need to document how my clients want it done, when to run what, etc. I put all this in my business process checklist. I also have some other items in here like what accounts to invoice when, how and where to file sales taxes, stuff like that. This is where all my non-development stuff lives.

My Actual DevOps Process For Web Design And Development

All the lists and processes in the world don’t mean anything unless I have work to put through my process. To simplify this example, I will be working on 4 websites at once. 3 for my customers, and one for myself.

Start of day:

Since all three source websites are WordPress, I need to grab those sites so I can grab the content and some of the stuff those customers want to keep like logos and other brand specific styles.

As part of on boarding, I changed everyone’s DNS nameservers to point at the cloudflare accounts that I set up for all the customers. I kept their current running configurations so their sites would stay live while I work on everything.

I light up Docker on my laptop. I already went to all the web servers and grabbed what version of Apache and PHP that they were running on.

$ docker pull php:7.2-apache
$ docker pull php:5.6-apache # the two older sites are OLD

I have a docker-compose for each of the sites that I will be running. They look something like this:

version: "3"

services:
  web:
    image: "php:<whatever version i need here>"
    restart: 'always'
    depends_on:
      - mariadb
    restart: 'always'
    ports:
      - '8080:80'
    links:
      - mariadb
  mariadb:
    image: "mariadb:${MARIADB_VERSION}"
    restart: 'always'
    volumes: 
      - /var/lib/mysql/data:${MARIADB_DATA_DIR
      - /var/lib/mysql/logs:${MARIADB_LOG_DIR
      - /var/docker/mariadb/conf:/etc/mysql
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}

Do Development Stuff:

Now that I have my docker containers spun up, I connect to my database instance and import the databases. After importing the databases, I change the URL’s in WordPress’s databases so I can access them with some dummy domain names that I set up in my local hosts configuration file (dev1.local, dev2.local and dev3.local). I grab the content I need from those sites. I clean up and convert them down to markdown since everyone is getting put into Hugo.

Hugo Stuff:

I create my templates for the various sites in Hugo. The nice thing about hugo is that you don’t need to do hosts trickery. When you work on a site locally, you just run:

$ hugo server- D 

This starts up a local web server and you can hit the site you are working on with localhost:1313 - so if I am in the directory with a given project, I just kick that command off and I can watch things change on the page as I make edits to various parts of the site.

Day 1 Roundup:

After a savage coding marathon, and I finish cleaning up the content from the legacy WordPress sites, I commit my changes to the various repositories in GitHub where those projects live. Once I commit everything to GitHub, it builds the ‘development’ branches that I have for those sites. I set up a branch called ‘stage’ which I merge all my ‘development’ branch stuff into. This builds on a project URL on Netlify that I gave to all my clients. I send them emails with the URL’s and an update on my progress, and request them to review what they see.

Day 2 Start:

In a perfect world, clients will respond promptly with edits and remarks. This is that perfect world, so all 3 of my clients got back to me. All my clients love what I did and they also love how quick my turnaround was for their redesigns and replatforms. the two older WordPress customers send me a few changes to make to their designs, and the blogger customer loved the turnaround but hated the design.

The sustainable culture lady wanted me to switch her to a cleaner masonry layout, which will be more involved. Since the process for ferrying her code into production is the same as the other three, I don’t have to do anything too special besides the complete layout change.

I make the minor tweaks to the first two sites, commit them to GitHub and send them the URL’s with the changes. They both give me the green light to deploy the changes live. I merge everything from stage into the master branch, and switch their A and CNAME records to point at their new hosting over at Netlify. Those new sites are now being launched. CloudFlare DNS changes are fast, but I told them to let their customers know that it might take a little while to see the new site.

After I get those first two sites launched, I get to working on the sustainable culture blog.

Constant Feedback:

Since I am set up to push changes to a place that is publicly viewable, I make a change, and send it to the sustainable culture blogger. She loves the masonry layout and wants to make more tweaks. She asks if we can have a 1 hour call later that day. Perfect, because I still need to work on my site a little.

When the time comes to talk to my blogger friend, I give her a call. She is on her computer and has a browser window open to the preview URL I sent her. She makes suggestions which I am able to commit in real time so she can see exactly how the page will look. She loves this because unlike her old developer, we can collaborate in real time. So after our hour long call, we have everything pretty much nailed down.

After working with the blogger for the last hour, I have her site pretty much ready to go. She made some new content that day so I have to go grab that from her existing WordPress site. This is easy since I just go to the site itself and scrape the content, cut, paste, etc. I write up some instructions on how to update her new blog using forestry.io (the back-end that I use with customers that update their own sites in Hugo). I send her the instructions and a note to take one last look on the preview URL.

Approval and Deploy:

The blogger gives me the go ahead to deploy and change her DNS over. I merge what is in stage with ‘master’ in GitHub, wait for netlify to finish the deployment, then I cut her DNS over. She is happy, I am happy, and now it is time o send out a round of invoices.

Everything is done for my first 3 clients. I didn’t go click by click on this guide because this post would be painfully long, but I wanted to give you, dear reader, a better idea of how this process works, and how DevOps practices in your agency can be a driver for you to rapidly iterate and deploy changes as well as entire projects.

Conclusion

As a web developer yourself, you know the back and forth that happens when trying to get projects out the door. You are also painfully aware that handling changes for projects can cause dependency issues that can sometimes take a few days to resolve. This has been as much of a case study in working with a DevOps stack as it has been an introduction to why I prefer Hugo over WordPress.