staging server, source congtrol, deply workflow using git

　　web项目开发中，有三个实践对于项目成功是非常重要的：

1. staging servers

2. Version control workflows

3. Tested, repeatable deployments.

Staging Servers:

什么是Staging server呢？基本想法是 staging=production-users。如果你是facebook,google那么你可能早已经有了成熟的工作流程，你已经有了一些具备多级staging/production的系统，你可以动态地更改他们。你已经有了一些天才为你工作，听听他们怎么想就可以了。这篇文章适合于那些没有为自己工作的天才的老板们，对于那些处于“要么在开发人员电脑上运行”，“要么在生产环境中运行”状态的团队。

为什么我们需要staging servers? 任何可能在生产环境会down机的情况都需要再staging server上首先发生！正是因为这个原因，你总是希望staging server环境和production server环境越接近越好。如果生产环境处理信用卡业务，那么staging环境同样也要处理信用卡。这意味着如果你的支付网关配置收到影响，那么你将在staging server上发现这个情况，而不是放到production server上才发现。如果你的production server使用ruby1.9,那么你的staging server也要使用ruby1.9.如果你的production server上使用memcache并放在12345端口，那么staging server上同样在12345端口上使用memcache.

配置一台staging server是很简单的。如果对你来说不简单的话，那么意味着你的infrastructure本身就存在问题了，只是你不知道而已：你可能是长时间地对你的production server粗制滥造，比如手工ssh到你的系统中,调整你的配置而没有任何关于你做了什么的log。你没有一个归档的过程或者自动化的脚本来从头创建你的production server.如果你有那个如何创建你的production server的归档记录或者自动化创建脚本，那么你一定可以在一个小时内把staging server搭建起来，而这个stagingserver基本上和production server是一样的。

大部分人可能没有能力这样做如果他们没有仔细思考这个问题的话。这是可以解决的，而且应该解决。这有实质性的好处：如果你有一个可以重复的过程来provisioning一个产品环境的话，那么有一天如果发生了系统崩溃，你将有信心在很快执行一个流程恢复系统。信心是很重要的，因为一旦发生灾难，你将无所适从，而无所适从的情况下，你是很难免于犯错的。所以一切有备无患。

保持你的服务器配置在一个脚本中比在服务器上分别配置多处（比如/etc/environment,/etc/crontab,/usrlocal/nginx/conf/apps/appname.conf etc)的好处是这个脚本可以放在版本控制系统中。你的cron jobs?如果他们本身也被版本控制，那么你将有你的系统变更的过程记录。

在你准备好了能够重复生产你的staging environment时，你可能希望做一个小小的修改。很多公司可能不希望他们的staging environment放到公网上，因为这样的话，客户不会在成熟之前看到系统的墨阳，而严重的问题永远不会影响到外面的世界。有很多种方式来这样做：理想地，你只要在防火墙上配置规则，任何从互联网上来的能够进入到你的staging environment.

我的staging environment仅仅包含ngix的一片小代码，它拒绝任何人的访问，除非一个特定的host被允许。这将会break和外部server的集成，比如twilio,spreedly，他们是需要callback的。所以我就对这两个url做一个例外，允许他们访问。

另外一个问题是：你如何populate一些数据到staging server上去呢？我通常使用seed脚本，手工增加一些数据。你也可以dump production DB并且加载到staging DB上去。