Website Drupal của bạn đã thật sự release và hoàn thành test chưa?

When we inherit Drupal sites for maintenance, I suggest implementing release control and creating a staging (test) site. When new customers hear this, they naturally ask why they need this. Frankly, they've never heard of any of this technical gobbledygook.

I've written this email so many times, I thought I would just publish it here and I can send folks this url.

git is a source control package. It allows you to track all changes to your code. It allows you to immediately revert to any version in the past. When the master repository is kept in a commercial repository (like bitbucket or github), the repository is also an effective backup for code. The Drupal database is not included in the repository.

In our development process, we usually have three distinct sites. First, there's the production site - the one that the world sees. Then, we have a staging site, often named staging.yoursite.com, dev.yoursite.com or test.yoursite.com. We put a username and password in front of this site so that search engines can't index it. Finally, a developer has a local, development version on his local machine.

1. When a developer starts working on a site, he/she pulls the production code from the git repository and copies the production database down from the production site. During development, he could potentially completely mess up the site and display disconserting errors, but only he sees it. If he did this work on your production site, your customers would see this.
    
2. When he gets the feature running as desired, he pushes his code changes to the repository. Then, he goes to the staging site and pulls these changes from the repository and makes any associated database changes.
    
3. The customer goes to the staging site and tests the change.
    
4. If the change is accepted, the developer goes to the production site and pulls the changes from the repository and makes any database changes required.

Without this workflow:

• You cannot easily revert changes.
• You are more likely to display errors to your customers.
• You still should do full backups, but the git repository can serve as a code backup.
• You can be testing one set of changes on staging while you're running the fully-tested code on production.

I hope that this post can help others quickly explain to the general business manager why release control and the staging/production workflow is worth doing.