It used to be that a large part of releasing changes to a professional website required a long list of steps to ensure secure propagation of changes through the development cycle into production.
Each part needed to be kept in sync with the next, or the whole flow would break. The test server would have to be in sync with the staging server, which needed to be in sync with user acceptance testing servers and ultimately the production servers. Each server having the same versions, patches and settings installed to ensure they were close copies of each other.
Next, you would make sure the databases at each stop were in sync enough to cover the minimum data requirements needed for that stage. In many cases, you would need to do all this again for your content management server and databases to ensure production content was not affected during testing. The lynchpin is that all these pieces needed to be set up the “same” and should be copies of each other without the redundancies, security and performance enhancements required for production. Due to cost, time, and implementation difficulty at the lower stages, there is always a fine line between “same” and exact. In the end, you would usually have a close enough match yet inevitably deal with bugs, due to the infrastructure, as you progress.
Finally, the need to sync everything manually required frequent backups and propagation, which typically meant no content editing or code changes during these often lengthy processes.
However, with Scrivito’s working copies and Netlify's branch deploys, there is no need for the typical setup demanding any of the above.
Working copies are virtual copies of the entire website content, much like branches in a version control system like Git. The currently published content represents the master, and for any changes to be made, an editor creates a working copy, no matter whether the app is run locally or from the deployed code base.
Publishing a working copy replaces the currently published content. It’s as easy and simple as that.
So now you only need one CMS instance. Developers can see whether code changes affect published content, or create a working copy and content based on code changes. This flows right down the line to each of the cycles. The added benefit is that the content can be used partially, fully, or deleted as code changes are moved to production. You can decide what works best for your team, working copies based on features, stages of the development cycle, or whatever meets your demands.
Netlify's branch deploys and previews can be set up to deploy directly from your remote Git repository. Typically, the “master” branch provides the production code base, whereas all other branches or those you specify get deployed as staging versions. You can even have pull or merge requests trigger preview deploys. The staging and preview versions are made accessible to you under prefixed URLs or subdomains.
This way, and based on only one CMS instance, each developer involved can see, for example, whether their latest widget looks and works as designed, simply by trying it out using a working copy.
There’s no need to maintain complex infrastructure or synchronize content to take advantage of multiple development environments. All you need is a Scrivito CMS and a Git repository, preferably at GitHub. Then, via your Scrivito dashboard, claim your site at Netlify, set up continuous deployment, and start developing. You might want to check out the Scrivito Example App as a starting point.