Tag! You're a Release!

Balloons being released

Past Self, Please be Kind to Future Self

What’s the difference between git and GitHub? What’s a repo? How is a release different from a deployment? How are tags and releases related?

Why is this all so confusing?

Building and maintaining a website used to be so much simpler. The site’s files sat on a server, and when you wanted to update it you’d just use an FTP client to push files up. Then people started making templates, so you only needed to push a few files up. But if something broke, it would break the entire site. Then you had the problem of how to reverse the changes you made; keeping track of things got progressively harder.

Smart folks with software development backgrounds started using version control software such as CVS (no relation to the pharmacy chain) to keep track of changes to the website code. Over time, as websites grew in complexity and more people worked on a site concurrently, it became essential, so people working on one part of the site didn’t break something that someone else was doing. This is part of parallel feature development.

Most of the early version control software had at least one major drawback—whether it was client-server based (meaning you couldn’t work offline), it didn’t give you the entire repository, it was insecure, or it was painfully slow and didn’t scale. And worse? Much of it was privately owned so access to it could be revoked.

This is exactly what happened to the Linux kernel. So Linus Torvalds, curmudgeon and creator of Linux, decided to make something better—something that was deliberately opposite of all of the other version control software at the time (2005). He made Git (warning, the page, much like Torvalds, contains profanity).

Git is often the source of developer’s ire, but compared to every other version control software it’s amazing. Free, secure, reliable, and best of all, most of the commands are normal words that describe what you’re trying to do. You want to pull code in from the original repository to your local repo? git pull. If something is in conflict, it will warn you, and mark the code where there is a problem. Compare that with a similar command from CVS: cvs -qn update -Pd.

Git quickly came to be the version control software for the free, open-source, and website software communities for all of the reasons listed, but it still only existed as something to use on a per-project basis, usually via the command-line. Each repository was separate, and there was no central way to search for projects, volunteer, etc.

Enter GitHub.

GitHub's mascot, Octocat

GitHub’s mascot, Octocat.

There were a number of websites that aimed to leverage Git, but GitHub had the advantage of being well-funded and early—and it has held the advantage by being the largest Git hosting service. Basic services are free, you can see (and work in) all of your repositories on the web, and you can search for, follow, and fork over 140 million repositories. It also provides a place for documentation, discussion, and task management. Plus, it lets you define a release.

To sum up where we are now:

The release page in GitHub can contain extra information to describe the changes to the code, tickets resolved with the release, documentation, dates, etc. This makes deployments to your website look more like a well-structured software release instead of an ongoing stream of small code deployments that are difficult to track and maintain.

Embracing Changes (to the CMS)

When your website is running on software such as Drupal, WordPress, or some other content management system (CMS), it usually saves changes to the CMS configuration in the database, not in code. Teams that work on CMS-based websites generally figure out how to export those database configs to code during development, so that changes made to the CMS don’t have to be manually re-made at every stage of deployment.

However, once the site is live, changes made on the live site become a problem—if a site administrator makes changes, e.g., to content types, search settings, or content access permissions, those changes need to be saved before the next deploy so they don’t get overwritten.

Having a tagged release is especially helpful for this problem, because it allows you to quickly checkout the code as it was at the time of the last release, download the current live database, and then export those live configuration changes into code for the upcoming deployment.

Once you finish your deployment, you can then tag the release in git, and when you push that tagged code up to GitHub it will allow you to create a release page with all of the details of your latest release. That means future you (or your coworkers!) can have a nice clean starting point for the next release.

And you should always try to be kind to the future you.

Get In Touch

Questions? Comments? We want to know! Drop us a line and let’s start talking.

Learn More
Get In Touch

Related Blog Posts

Meet Our New Support Team

We know that balancing the ongoing needs of your website, your team, and your users can be a real challenge. We have developed a clear set of priorities and checkpoints to ensure your digital properties stay secure, up-to-date, and optimized for the long haul, and re-structured our process with those priorities in mind.

Talking to Screen readers with ARIA-live and Drupal.announce()

If content changes on your site and there’s a visual change to let users know, you need to make that change clear to folks who can’t see the visual cues. Drupal.announce is a JS method built into Drupal core that can make this easy.

Fast, Relevant, and Easy to Read

Building a site today is more complex than ever. Front-End developers need to balance the requirements of a design, the tools best suited for implementation, the long-term maintainability of the site by non-developers, and the ever-growing legal risks that can be part of a high-profile client site.