When we develop sites we start off locally and in a development environment. During the development process we continue this process as we evolve the design and functionality.
But there comes a point where the site we’re working moves to the stage where it will become the live site. At this point it’s preferable to move it to the live environment.
We try and match development and live environments as much as possible but it’s not always possible to get exact matches due to various constraints.
By working on a live environment as early as possible any differences in configuration such as file permissions can be worked out early on.
With PHP and Drupal moving to Composer based workflows there constraints on PHP versions for different modules. Even Drupal will be implementing a minimum PHP version. Discrepancies like this need to be spotted and resolved as early as possible to ensure the site functions as expected when launched.
As I talked about in my previous post on Handling Existing Content, we often import content and do some manipulation of it. Further to this both the client and team at Headscape will add additional content.
We don’t want to risk this being incorrectly updated or lost. Having a copy of the site on the live server gives a clear distinction as to where the true source of content lies.
File uploads is another source of content that should not be ignored. By working on the live environment you ensure that file uploads and access work correctly, as described above with regards to permissions.
It also saves a time consuming task of moving any uploads from a development environment to the live environment before launch.
It’s rare to work on a site that does not include an SSL certificate. Even simple sites often have a contact form so data can be securely sent and combined with search engines ranking https sites better it makes a lot of sense.
I won’t go into detail here but in a previous post I detailed how to test an SSL certificate without the domain name.
Overall working on the actual live environment provides a nice level of reassurance before you make that all important DNS switch.
A simple thing like ensuring the server is correctly sending out emails can make launch day an enjoyable experience rather than a mad scramble to debug why your killer feature isn’t working as expected.