A Better Web Development Workflow

I've been developing websites for almost a decade, and I can remember back when I started using tools like Coda and developing right on the server. Don't judge me, if you're a developer you probably tried it too.

Far more common was to develop on a local environment and then FTP the whole site up, which was slow and created downtime while files were being overwritten, etc.

Luckily those days can be behind us using modern web development and deployment tools like Git and Buddy.

So here's the high-level idea, assuming you're familiar with version control systems.

Git-flow Workflow

Utilizing the git-flow workflow made famous by Vincent Driessen at nvie, we can ensure that only production-ready, release-ready code is in our master branch

The develop branch is the source of all of our support branches that we'll do any development from. From the develop branch, we'll create feature and release branches on our local machines that will get merged back into the develop branch.

Multiple Environments

Often when developing websites, you'll have multiple environments that the website is running on.

Local - The local environment is running on your local machine and is where you'll do all of your development.

Staging - A staging environment is an environment where stakeholders can access the website. This environment is great for allowing stakeholders, members of marketing and content teams, and other vital people to access the site to perform audits and quality assurance tests before the site is made live to the end-users.

Production - The production environment is the primary environment for your website that is accessed by the end-users.

Code Up, Data Down

When managing multiple environments, a best practice is to implement a code up, data down workflow. This means that changes to the codebase are pushed up from local to staging to production.

For CMS driven websites like CraftCMS and Wordpress, the content on the production environment is in a fluid state as it can be updated at any time by content editors. In this case, we don't want to write over the data in the database with the data from a local or staging environment because it's likely that it's out of date — That's why data always comes down. When working on a new feature, or updating the site, it's best to make a backup of the production database and import it into the staging and local development environments.

Making Deployments Easy with Buddy

Now that we're developing using multiple environments and using git/git-flow, we can set up a deployment pipeline that makes updating our site on multiple environments easy.

Buddy is a great deployment tool, with an excellent user interface that makes building production pipelines a breeze.

In our git repository, you should only be committing source code, not build files. We can utilize buddy to build and compile our code that's needed at runtime.

Here's an example:

1. We're building a Wordpress websites

2. The repository is the whole wp-content folder

3. Our hosting platform gives us SFTP or Git push access

4. When we push code to the development or master branches, Buddy can automatically download dependencies, build our CSS and javascript, minify our images, and deploy those changes to the respective staging and production environments.

5. Notify you via email, Slack, or a webhook of the build status

So Why Update Your Development Workflow?

1. Keep your git repository clean and easy to understand by not committing build files.

2. Create peace of mind by having a staging environment you can test your website on and share with others.

3. Improve the developer experience and work more efficiently on a team.