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上去。

你可能感兴趣的:(workflow)