How do we setup a proper development workflow?

When I built my first website, I remember I had only a few files and a couple of folders in my development project. These were mostly single-page websites, everything was neat and quickly accessible. Later on, I started building websites with their own content management system (CMS), containing hundreds of files, from markup to scripts, libraries and stylesheets, to different sorts of media files, back-end services, and more. How do we organize and properly maintain larger projects?

At first, I had no clue how to structure an architecture that can adapt fluently to changes and future updates. I didn’t yet understand how everything works, so I automatically thought that setting up a performant website was very complicated. In fact, the more I searched on the Internet, the more I was discouraged to move forward. I kept hearing about new frameworks and about new techniques, and tons of other methods that different web developers persisted that I should use as well. Instead of confirming what I thought is clean, simple, and right, I was confronted with many buzz words that I didn’t yet understand or heard of. From my research, by reading quality books and well-curated articles, I noticed that I didn’t know if what I choose would be the right decision, and I kept insisting with myself that I wasn’t ready yet — or so I thought. I was wrong.

The problem is that right or wrong doesn’t exist in web development, it is not defined in some Internet “mastery” book. The core architecture and the development structure of every website can differ completely from one another, but the basic construction of a website is very simple and straightforward. Different web browsers and web servers work in their own unique ways, and your challenge will always be to keep testing your products against new updates that might affect your website on these platforms. Browser vendors, network protocols, and web servers — as long as your website plays nicely around these three technologies, you can literally do whatever you want. At the same time, this doesn’t mean that certain standards and methodologies do not exist. As years passed by, web developers have come up with a few methods and techniques that paved their way as the industry standard. This is because they make technical sense, and following these defined and robust methods can help you build a proper structure and an architecture that you can easily maintain and adapt.

In this chapter, we’ll be looking at various ways web developers apply strategic methods to continue improving their web development workflow, and to easily keep their websites updatable and future maintainable. Setting up the right workflow is also very crucial to reach the best productive outcome, and whether we talk about the front-end presentation or the back-end services, everything starts from the local environment you set up on your personal computer. That’s what we’ll start talking about first.

Creating a robust local environment

When you design and develop your website, you should always try to apply the same behavior on your local development environment to match that of the live web server you will use. This will range, for example, from the type of web server you choose (e.g. the Apache HTTP version) to the back-end language version that you have installed on both your remote server and your local computer. By using this method, you can heavily reduce the chance that something will go wrong once you publish your website live. It’s usually also crucial that if the project is a long-term project, you keep notice that if some updates are done on the server, you apply the same updates on your local environment before you start any work. This lets you revisit the project several years later, apply certain updates or patches, and deploy to the live server resting assured that you don’t break the live production.

Some web developers recommend that you install a virtual machine (VM) for every individual project on your computer, so that it behaves the same as your live server. While this is a powerful and versatile solution, the downside is that it will drain the resources of your host machine — your computer. My own preferred way of dealing with this was to always have a staging (testing ground) version of the website on the live server.

This means that if a project I worked on was running live on the URL ‘example.com’, I created a sub-domain with ‘test.example.com’, and I deployed the updates on the staging area first to make sure that nothing breaks. This can be in any other directory, as long as it runs on the same server environment. Personally, this gave me the right confidence to deploy any changes or updates on the live server, as from my experience, your local environment will never behave the exact same way, even if you think so.

If you keep this in mind from the very start, you’ll be able to apply the right strategies, since the way you structure your website on your local environment will be the same way you’ll have to maintain the structure of your production version running on your server. The simpler the structure of your local environment is, the easier it will be to maintain both. For now, keep in mind that you will always have two environments of the same development, one living on your local computer, and the other on the web server.

This article is a section taken from Chapter 4 of the eBook ‘Mastering Web Development’. If you would like to read more, you can also download the free Sample Chapter from the website here.

Thank you for reading!

I would really love to hear your comments and thoughts — critics are always welcome around here too. Which are some of the best strategies you use to maintain a proper development workflow?

Until next time,
Owen Far