When working with placeholder sites, always fork and change shortname for full build

[kerrygilbert]

From @boutell:

For Rebuild, we decided to greatly upgrade their existing site, and build the new production content on staging, while keeping the old single-page version of the site on their production server.

Tonight I did what somebody was inevitably going to do. I typed "sc-deploy production", broke the single-page site, and wigged out. Fuuuuuuuuuuuuu

After flailing around thinking about backups I realized that since I hadn't synced any content, I could just use sc-rollback to get back to the last deployment of the old single-pager code.

But this illustrated that the whole workflow for this was a bad choice.

For now I have renamed settings.production to settings.NOT-YET-production so I won't make this mistake again.

But we still have the client building content on our testing server, aka our "staging" server, which is risky and generally a bad idea.

This is what I think we should do next time:

If the new version of the site is basically "all new," we just fork the darn project! New repo name, new shortname. Then we can safely deploy them side by side to their production server.

This comes up every now and then when working on a client project that requires a "single-pager" or "place-holder site". We put up a temporary site that will eventually be replaced by a full-featured A2 build.

An issue arises when it's time to deploy the new full-featured site to the production server so the client can enter content, but the placeholder page needs to remain untouched...

The answer:

The full-featured site should be a fork in Github with a different name. This project should get its own shortname so the databases won't conflict.