Tools I use to bridge this gap and speed up development:

• Vagrant
• Docker
• VS Code + VS Code Remote
• Git
  

Summary

• Keep your development environment as close to the production environment as possible. (Vagrant, VS Code Remote)
• Keep your production requirements as flexible as possible. (Docker)
• Take advantage of environment variable separation where possible. (docker-compose override)
• Version Control the whole solution. (GitHub)

Vagrant

In the near future (2020) windows will include "native" support for docker with WLS but until then I recommend using vagrant for local development.

Using vagrant for development helps to simulate and practice the process of connecting to a machine and issuing remote commands, after all this is what we will be doing on our server.

You can even pick a vagrant image that matches your hosting machine, in fact I recommend it. My digital ocean hosting uses Ubuntu 18 with docker and docker compose included. Well guess what?! Vagrant has an Ubuntu 18 image and a docker provisioner. This gets my development environment to almost 100% replicate my production environment.

In order to get the docker provisioner you will need to run this command to install it:

vagrant plugin install vagrant-docker-compose

Here is my vagrant file as an example:

Docker

Docker lets you build up your software from separate parts. Pick a web server, pick a web application framework, pick a database. You can keep each of these concerns separate, and connect them where needed. Need more database storage down the line? Just migrate that one docker container over to a database hosting service. And the beauty of it all is its super easy to migrate between servers.

Another great feature of docker-compose is configuration file overrides. For the situations where you require different configurations between your environment you can create separate docker overrides to extend the base configuration.

Version Control

I recommend creating two branches one for production and one for development versions. I would make all modifications and feature implementations first to development where you can test them before merging them to the production branch and pulling the changes to the production server.

Depending on the scope of your project you could get more granular and create branches for each feature implementation and merge those to dev branch separately and test them there and then merge to production branch.

Version control is such a powerful tool and Github makes so many of these features so accessible and intuitive. Using pull requests and code review stages are great development practices and are so easy with GitHub's web interface.

VS Code & VS Code Remote

This is an extension for vscode that lets you connect vscode to your remote server as if it is local. You get your familiar project window but you have real-time control over your server. Fantastic.

In a perfect world we could publish changes with the push of one button and everything would just work however this is often not the case. Commands need to be run, packages downloaded, databases migrated, configuration files tweaked. VS Code Remote makes this a breeze. No longer do you feel like you're flying blind; pushing an update to the live site and to have no clue whats going wrong.

Another VS Code recommendation I would make is customizing the color theme on a branch by branch basis. Using Vs Codes workspace settings you can create custom title bars for production environment and development environment so you never get confused with which code server you are working in. These can be setup in the version control branches once so you can get these customizations on any workstation.

Production Settings:

Development Settings:

Transitioning from development to production and juggling these two environments can be difficult. These are the tools and setup I can recommend that are working for me. I will be sharing more about my docker setup with php, laravel framework and Twill cms soon.