There are a lot of moving parts under the hood of a website, and we take great care in making sure that they are working together smoothly. A common question we get is just how all the code is managed when we’re building a new site, adding new features, and working on bug fixes. Often times, there are multiple engineers that need to work together. Though you may never look at a single line of code, it’s still nice to understand how things work for an extra bit of peace of mind.

Where the Code Lives

The first thing a developer will do on a new project is create a brand new repository on GitHub. This is a private, remote place for the code to be stored. From there, we can give access to as many people that need it, and we can also use another tool to send it off to a server, similar to uploading files via FTP. With GitHub, we can see all the branches that have been made, and who is making what changes, but we’ll get to that later.

Multiple Website Locations

Your site will live in more than one place, so that we may run many tests, and make sure things are ship-shape before publishing it live. Here’s a basic view of how that works:

1. Local
Your developer will set up a web server environment on their computer just like the one your host provides. This will let them make a website locally without even needing internet access. It’s where they will test their code before it goes anywhere else.

2. Staging
Once a layout, feature, or fix is ready to be reviewed, it gets sent off to a staging site. This is a secure, private website just between you and your developer, where we can take a look at changes and play with test content.

3. Production
This is the actual, live site that the whole world sees. 

Git Commits and Branches

“Git” is the name of the version control system that we use to manage code. When your developer makes a change on their local environment, they’ll commit it to the repository with a message that explains what the changes mean. Then, those changes get pushed up to the remote repository on GitHub. Another developer is then able to pull the changes, if they need them. But rather than working with a single codebase, we use different branches to keep from bumping into one another, and to separate features and fixes.

The master branch is where production-ready code and features are stored. It gets deployed from GitHub to the production server. Staging is the git branch where we do all of our new feature testing and hot fixes, and it deploys to the staging server. When we want to add, “feature abc,” for example, we copy master into a new branch and call it, “feature/abc.” We then make all of our changes there and test it locally. When it is ready for you to test on the staging site, we merge “feature/abc” into staging, so that it will become visible on the testing site. Once the feature or hotfix is approved, we then merge “feature/abc” into master, so it can go to the live site.

Using the feature branch method lets us work on multiple features and fixes at once. Let’s say in the middle of testing “feature abc,” we need an urgent “hotfix xyz.” We can follow the same steps as before; create a new branch from master, test on staging, then merge “hotfix/xyz” into master. Since it is separate from “feature/xyz,” we can deploy it to the live site separately.

What about Content?

Each site will be its own separate install of WordPress, local, staging, and production. This means they each have their own database. The database is where content is stored. If your developer edits a page on his local site, that change will not be made on the staging or production sites. The same is true for any of the sites. Content is managed separately, and never the twain shall meet. This is great, since we might want to test out how a new image or a change in text will look on a page. We can do that on the staging site and look at it together before we make the same changes on the production site. Another example would be writing a new blog post. Most likely, the best place to do that is straight from the production site. WordPress provides a way to preview these before you publish, so there’s likely no need to test them elsewhere.

We’re so happy that you’re working with us to meet your goals. If you are looking for a long-term partner that will grow with your business, then you’ve come to the right place…we’re in it for the long haul!