With this method, we control the files on a site via CVS. In this example, there is one development site and one production site. The only way files should move between the two is via cvs. The production site could run "HEAD" from cvs (raw example from chat log:)

1) change the file on dev as desired
2) test the new file
3) commit the file: 
if the file is /web/foo-dev/www/index.adp, do: 

cd /web/foo-dev/www
cvs diff index.adp (this is optional; it's just a
reality check)
the lines starting > will be added and the lines
starting < will be removed, when you commit
if that looks okay, commit with: 
cvs -m "changing text on front page for February conference" index.adp
the stuff in -m "foo" is a comment visible only from within cvs commands
4) update the file on production:
cd /web/foo-prod/www
cvs up index.adp

The drawback to using HEAD as the live code is that you cannot commit new work on the development server without erasing the definition of 'working production code.' So a better method is to use a tag. This guarantees that, at any time in the future, you can retrieve exactly the same set of code. This is useful for both of the characteristics of safe change deployment. For control, you can use tags to define a body of code, test that code, and then know that what you are deploying is exactly that code. For rollback, you can use return to the last working tag if the new tag (or new, untagged changes) cause problems. .... example of using tags to follow ...

The approach taken in this section is to always create a new service with the desired changes, running in parallel with the existing site. This guarantees control, at least at the final step of the process: you know what changes you are about to make because you can see them directly. It does not, by itself, guarantee the entire control chain. You need additional measures to make sure that the change you are making is exactly and completely the change you intended to make and tested previously, and nothing more. Those additional measures typically take the form of source control tags and system version numbers. The parallel-server approach also guarantees rollback because the original working service is not touched; it is merely set aside.

This approach can has limitations. If the database or file system regularly receiving new data, you must interrupt this function or risk losing data in the shuffle. It also requires extra steps if the database will be affected.

Simple A/B Deployment: Database is not changed

Figure 6.2. Simple A/B Deployment - Step 1

Figure 6.3. Simple A/B Deployment - Step 2

Figure 6.4. Simple A/B Deployment - Step 3

Complex A/B Deployment: Database is changed

Figure 6.5. Complex A/B Deployment - Step 1

Figure 6.6. Complex A/B Deployment - Step 2

Figure 6.7. Complex A/B Deployment - Step 3