[SalesForce] Unable to refresh Sandboxes

Take a look at this document :

https://help.salesforce.com/HTViewHelpDoc?id=data_sandbox_create.htm&language=en_US

Users can log into the sandbox at https://test.salesforce.com by appending .sandbox_name to their Salesforce usernames. For example, if a username for a production organization is user1@acme.com, and the sandbox is named “test”, then the modified username to log into the sandbox is user1@acme.com.test.

> Note Salesforce automatically changes sandbox usernames, but not passwords.

The main disadvantage of bi-weekly refreshes is that you may lose some time if the queue happens to be backed up. The best you can do is try to schedule Friday afternoon and hope it's ready by Monday (or whatever weekend you observe); if you lose a day, you've lost 10% of your total productivity waiting on a refresh, compared to a quarterly refresh, where a day setback would result in the loss of about 1.7% of your total productivity time. The main advantage, of, course, is that the orgs are naturally more up-to-date than a longer cycle, meaning fewer merge sessions and fewer accidental overwrites. Unless you're using a clever locking scheme, like perhaps subversion, you'll come to appreciate this.

The main disadvantage of quarterly refreshes will be noticeable if you deploy to production more frequently, which will eventually be a sticking point as it gets harder to develop and not overwrite other changes and/or keep the most recent code in the SubDev boxes. The longer you go between refreshes, the more upkeep you'll encounter unless you have some intelligent code synchronization tool to keep things organized. This means more time merging, more time tracking down accidental overwrites, and more overall housekeeping. In other words, you'll spend less time developing the longer you go. Anecdotally, just in the last week, I had to merge about 6,000 diffs into my sandbox because it's outdated, but I can't afford to refresh right now. We're not on a very strict cycle here, although we're working on it.

What seemed to work decently well at my prior job was to have two week sprints and a release cadence of four sprints, with the sprint leading up to release weekend being used only for QA, last-minute fixes to the code to be sent to production, and other last-minute activities. Sandboxes were refreshed once per release. We also had a Git repo that we'd use to sync code back from the staging org back into the individual developer orgs to keep them fresh. This minimized downtime between releases.

A proper agile implementation would want to experiment with the best cadence to use, but you should probably consider choosing a release cycle of somewhere between one and three months, and try to avoid releasing code in between those releases, except, obviously, for hotfixes/critical errors, and choose a sprint cycle that provides at least 25% of the time for housekeeping like unit test updates, refreshes, code merging, etc. The two month release cycles included an entire week of post-release refreshes and dealing with any emergency fixes/issues during the first sprint and the one week pre-release activities, like last minute hotfixes, etc, or about 75% development productivity.