We operate a Quality Assurance- and Change Control- Process.
This allows us to version each update to the code, styles, and scripts of your website or application. Simply put, each version of your website’s code is tested first in our development environment, then in a staging environment, then on the live server for as much as possible. This process is called Quality Assurance (QA).
Versioning your website’s code allows us to pinpoint exactly which lines of code were changed between each version, accurate to a single character. This, in turn, allows us to revert or amend those exact lines of code should an issue arise.
Every change to your website is attached to one or more workitems in our source control system. Each workitem describes exactly why the changes were made. For example, to resolve a defect (a “bug”) or to add or amend functionality.
If your site is hosted on our private infrastructure as part of a fully managed solution, then none of this matters to you. Apart from that you are now in the knowledge of us following best practices on your behalf!
Using your own hosting provider
However, if we maintain your site or application for you on your own hosting provider, you may have direct access to the files on the server through FTP or some other file explorer. In this case, it is important to understand that you should never make changes to these files directly!
When we deploy changes, we do so using a package of an entire version of your website. All your website’s code files are included in this package, so any changes, other than content, you (or someone you employ or contract) have made, will be overwritten.
We strongly suggest that you change all your passwords for your control panel, FTP access, File Explorer, etc. so that no unauthorised access is possible. Anyone who requires access, should use a named account. So your contractor called Bob, should FTP using an FTP account called Bob. Simple.
Nevertheless, we still wouldn’t like Bob to change files directly. As we mentioned, these will be overwritten the next time we update your site. Bob should simply get in touch with us so that we can include his changes in the next version of your site. If Bob makes many changes, we’ll give him access to our source-control system so that he can include these changes directly.
This way, Bob’s changes will go through the change-control process, they get tested in the development and staging environments, we have a workitem with the details of his work, we can report back to you on the work committed, and life becomes generally a lot easier.
Content is King
Of course, any changes you make to content (text, images, etc.) through your CMS, for example WordPress, Orchard or Presence, do not necessarily have to go through change control. We leave that up to you and your marketing department. Having said that, WordPress is often accessed with administrator rights by every Bob and his uncle! Consider changing your administrator password and restricting your WordPress users to just the permissions they need.
- Change your administrator cPanel, FTP, WordPress, Orchard, etc. passwords and store them away safely.
- Every employee or contractor who requires access, should have his or her own logon, either to the CMS, the cPanel or FTP.
- Restrict access to any cPanel and FTP for those who do not need it: Which is probably almost everyone!
- Create CMS roles (e.g. in WordPress or Orchard) with just the right permissions and assign these to your employees.
- Force password updates and change important administrator passwords at least every 90-days.
- Ensure all technical staff is aware that any changes made directly to the files on the server may be overwritten!
Thanks to our many years in the industry we fully understand the need for these controls. These easy to implement constraints are nothing compared to the serious security regulations we should strive for, but it's a start. It is, however, also our experience that at least 95% of small businesses give away their administrator usernames and passwords without a second thought.