Skip to Main Content

Git Workflow - Reflections of a solo developer

I just started using Git in January of this year, I've known about version control and the benefits for several years, but never felt like it would benefit me as a solo developer. How wrong I was.

I just started using Git in January of this year, I've known about version control and the benefits for several years, but never felt like it would benefit me as a solo developer. How wrong I was.

When I was working full time at an agency I more and more felt the need to be using version control, but I was unable to get everyone else on board due to a number of factors. These included people not wanting to improve or learn, One of the project managers liked to dabble in CSS and would tackle client requests live on the server rather than pass them on to me, and the time taken to learn would reduce time available for client projects.

In January, I decided that I needed to learn Git and took the plunge on a small personal project with which there would be no impact on anyone except myself if mistakes were made. Turns out there were no real issues.

I've been thinking about writing this post for sometime now. Today on twitter Patrick Pohler mentioned the article he had written, in September, Git workflow: Manage code complexity, which inspired me to do the actual writing.

How I learned

To learn git I watched a series of YouTube videos which helped me solidify what I'd picked up from reading various articles.

After watching these videos I was still a little unsure how to get deployments to the live server working and the video tutorial that made it all clear was from Mijingo, which was 100% worth the $20, currently $15.:

Tools

The tools that I use are:

  • SourceTree (Git Gui) - opensource and cross platform. Dead easy to use.
  • Command Line - rarely as the gui means I don't need to remember various arcane commands. but sometimes it's necessary.
  • Bit Bucket - Free private repos (GitHub charges for private repos)
  • Dploy - deploy code to staging/production
  • Navicat - Remote access to database, db dumps, imports, data transfer and more. Way better than phpmyadmin
  • FocusLabLLC Master Config - Sets EE up for multiple environments

Workflow

My workflow is pretty simple. I've created a default install of ExpressionEngine default install, which as everything set up the way I like it, including, bootstrap, a simple index template, various EE settings, file directories, client member group,, database dump, javascript, and sass files all preconfigured.

  1. The first step is to create a project in Bitbucket and then clone that empty project to my local computer.
  2. I then copy and past the default EE project, minus the .git folder into the empty project
  3. Open Navicat create a local db, import the default.sql dump
  4. open /config/ which has the FocusLab master config files and enter the config.local.php db credentials. Open config.env.php and enter the local/staging/production domains
  5. Login and confirm that everything is working correctly. If it is, then I do an initial commit and push everything to BitBucket
  6. Create a Development Branch and Start Building out the site.
  7. Once the site is ready for the client to preview and/or enter content, it's time to set up the staging environment.
    1. Create your db, and staging environment - I have a specific dev domain that I set up subdomains for all my clients.
    2. Enter these credentials into config/config.stage.php (FocusLab master config)
    3. Login to Dploy.io and connect a new Repository, enter the sftp/ssh credentials and set it to auto deploy from the Development branch. Deploy your repo.
    4. While the site is deploying open up Navicat, create a staging connection and test that it works. Assuming it does, close the connection, open your local database and do a "data transfer" to the staging server. This does a direct transfer to the staging server. No need to take a dump and then import.
    5. Check that staging site works.
  8. Now that we have a staging site, workflow changes a little. At this point any changes to the database need to be done on Staging and then moved to the local database either by a "data transfer" or by dumping/importing. Template code, is done locally and pushed to the staging server. Workflow has two different directions:
    • Database (channels, fields, entries etc) Staging ---> Local
    • Code (HTML, JS, CSS, PHP etc ) Local --> Staging

Production!

Woo Hoo! the site is done, the client has entered all the data and has approved the site to go live. At this point you repeat step 7 above but set Deployment to be manual, i.e. you have to login to dploy.io and click a button to deploy the site. This ensure there's no accidental deployment of code that's not ready. The deployment branch should be set to Production or Master.

In the future when changes are made to the site, you would work on the Dev branch, push to staging, get client approval, Merge to Production and push to production.

Benefits to the Solo Developer

There are several benefits to the solo developer. No longer do you need to create duplicate tempates and make changes there or inform your client that there may be some wonkiness on the site while you do the work they've requested. No more worrying about accidentally deleting/modifying something and then having no way to recover that file. All changes are version controlled allowing you to easily roll back your changes.

Collaborating is easy. But wait, I"m a solo developer? Are you really a solo jack of all trades developer? Have you ever needed help on something either due to time constraints or perhaps your skillset doesn't cover something you need done. Git let's you share the repo with another developer, they can do their work and you can then see it before merging it into your staging/production branches. Brilliant.

I'm a solo developer, but I also do a fair amout of outsourcing work for other agencies. Either as the sole developer on the project or as part of a team. Using Git has opened up work opportunities for me that I would have otherwise not been able to do. I can clone an existing project from the agencies repo and make my changes and push back.

GIT-ifying an existing site

Converting an existing, ExpressionEngine, site to Git is super easy. Copy the site to your local server. Drop in the FocusLab Master config files, get the site working locally including upload directories. ONce that's set, set up a staging server and test. Finally set up the live server in Dploy, move existing site to a new folder (I call it DELETE_me_later) and deploy. There will be a few minutes of downtime, but you can easily schedule that at a time the client is comfortable. Now your previous projects are ready to use git workflow.