Building a website is often a highly collaborative effort with many different moving pieces. One of the toughest to coordinate is where the team builds it. Should your team be working directly on a remote server or on their own local copies? Does it even matter?
Working directly on the server where your site lives can look enticing. You can work with your team live and very quickly everyone can see the state of the website. Code is confirmed against an environment that has same architecture as the production one (Or directly on the production environment, but you’d never do a terrible thing like that right?) and you have a low chance of running into a case where your code doesn’t work when you deploy.
Unless you are working solo, developing directly out on a server can be a bit hazardous. If two people are working on the same file out on the server at the same time, you can have lost work pretty easily. This is especially a problem in a world where your team isn’t using some sort of version control. (If you aren’t, you really, really, should be.) While better, this still isn’t a perfect solution as your team will be pushing frequently to confirm and debug every single change they make. This will likely cause some slowdowns for the workflow and it is more likely that a breaking change can cause downtime for the team.
What do you mean it doesn’t work out there?
The answer would seem to be that developer should work locally since that helps prevent them from running over the work of their teammates and they can confirm the changes they are making work before pushing them out to the development server. The problem is that working locally can mean a lot of things to a lot of people.
There are a few ways to get a version of your site working on a local machine and depending on your machine, you might already have all that you need. Linux and Mac systems already have the ability to get this going locally pretty quickly. If you are running Drupal, you just need to turn on a few features and you are ready to go. Windows users aren’t left out as there is plenty of software that is available to quickly turn your computer into a local web server.
So your whole team has a local copy of your site and everything is going smooth. Working in parallel will greatly increase efficiency of multiple developers on the same project, but what is the setup that everyone chose? Is one developer coding around something they have support for on their machine that another does not? These are the types of things that happen real quick in this situation and can lead to some rough deployments. Not to mention, that if one of the developers has a computer issue they will have to remember everything they did to get their local setup working again.
Bringing consistency to your development
If working out on the server sounds like a bad idea and working locally sounds like a scary project too, then what are you supposed to do? It’s time to think outside the box a bit and start using a virtual machine. This can be a bit of an undertaking if you aren’t familiar with setting up a server environment and you’ll want to get some sort orchestration piece in place so you aren’t back in the same spot with different developers setting up their local environment differently. As tough as that can sound, it will definitely improve workflow and developer frustration if you can put something consistent in place.
Don’t want to be in the business of maintaining servers? Even if it is local? There are other solutions out there that do a lot of the work for you and I have some suggestions if you use Drupal especially. DrupalVM is a great solution for this as it is highly customizable, you can get close to production parity, and it is built with Drupal in mind. You will have to play with the settings a bit to get it there, but it is fairly ready to go out of the box. Another great option is Lando. It is based on a more container-based architecture and supports more than Drupal out of the gate, so it could be a great option if you work on a variety of platforms.
I’m not a developer… Why should I care?
If you aren’t a developer, this might all sound like something that isn’t all that important, but for the sake of stability and predictability it is something that can’t be ignored. Many web teams have switched to this method of development, because there are fewer surprises at the end of a sprint. Developers don’t like surprises and neither to clients. Switching to a predictable development environment will definitely help with that.