When I first joined Motto as CTO years ago, the developers would have a development server, either in the local network or remote, to which they would FTP transfer every file edit they needed made. This obviously wasn’t ideal because:
- It was slow. Download file, edit, upload, reload website was way too many steps to previewing an edit to your code if you ask me.
- It was dangerous to collaborate. Oftentimes another developer would jump into the project, or sometimes even the original developer after a certain amount of time, and accidentally overwrite new code with old code because their local files weren’t up to date
It was relatively primitive, and so I immediately implemented Git versioning with the team which went hand in hand with the concept of setting up a local development environment.
This was a big step forward for our development process at that time, but looking back, it also had its advantages:
- It was consistent. Oftentimes even our local environments were slightly different and so it led to errors on one developer’s system but not anothers. This has largely been solved by Docker containers and more controlled local setups, but at the time it was still annoying. Using a shared dev server to edit on gave all of its developers the same end-product.
- Way less time spent on setup. Because development was moved to our local computers with Git, we needed to set up a local environment for each site. I implemented all sorts of tools and protocols to make this as easy as possible, but at the end of the day, we lost countless hours in setting up local web servers, debugging issues, switching between versions and all sorts of dev ops issues that my team of web developers shouldn’t have had to deal with. With a remote dev server none of this was ever an issue. Our sys-admin provisioned a few environments once and our developers dropped their files in. Rudimentary? yes – but it worked.
- Computer Resources. By the very nature of versioning our code it means every developer has their own copy. And as discussed, by consequence, their own copied environment to run that code. This led to an enormous surge in resources our developers needed on their computers especially in terms of storage space. For a product development company with a few project repositories this might not be an issue, but as an agency, we often had our developers working simultaneously on dozens of different projects they needed to have setup locally on each individual’s computer. Back in our caveman days, our centralized dev server solved this completely.
So how can we combine reconcile these two scenarios in light of working exclusively with WordPress block themes?