应用程序发布与部署中的几个小Tips

应用程序发布与部署中的几个小Tips

真正执行部署操作的人应该参与部署过程的创建

在一个项目启动时,开发人员首先要做的一件事情就是非正式地找到运维人员,让他们也参与到开发过程中。这样,运维人员从项目一开始就已经参与了软件开发,双方都知道在发布之前发生了什么,因此,这就会像新生儿的屁屁一样光滑。

记录部署活动

如果部署过程没有完全自动化(包括环境的准备工作)
,记录哪些文件在自动化部署过程中复制和创建,这是非常重要的。这样做之后,很容易对发生的问题进行跟踪调试,因为很清楚在哪里能找到配置信息、日志和二进制包。

同样重要的是,在每个环境的部署过程中,记录每个改动过的硬件清单和实际部 署的日志。

不要删除旧文件,而是移动到别的位置

当做部署操作时,确保已保留了旧版本的一份副本。然后,在部署新版本之前清 除旧版本的所有文件。如果旧版本的某个文件被遗忘在了最新部署版本的环境当中,
出现问题后就很难追查了。更糟糕的是,如果旧版本的管理接口页面还留在那儿,那 么很可能引起错误数据。

在UNIX环境中,一个最佳实践是:把应用程序的每个版本部署在一个单独目录中, 用一个符号链接指向当前版本。版本的部署和回滚就只是改一下符号链接这么简单。
对于网络版,可以把不同的版本放在不同的服务器上,或者在同一服务器上使用不同 的端口。如10.4.3节中所说的,通过代理切换的方式在它们之间切换。

部署是整个团队的责任

“构建和部署专家”的存在是一种反模式。团队中的每个成员都应该知道如何部署, 如何维护部署脚本。通过每次部署软件(
即使是在开发机器上)都使用真正的部署脚 本,就可以达到这一点。

如果部署脚本有问题,构建就应该失败。

服务器应用程序不应该有GUI

在过去,有GUI的服务器应用程序是很常见的。尤其是PowerBuilder和Visual
Basic构建的应用程序更常见。这类应用程序经常存在之前提到过的问题,比如配置信息没有脚本化、应用程序对安装在什么位置非常敏感,等等。然而,最主要问题是:
为了能够正常工作,该机器必须有一个用户登录并显示一个界面。也就是说,系统重启(比如由于突发事件或正常升级)
都会令该用户登出,而服务器也就停止了。之后,维护 工程师就不得不登录到那台机器上,手工启动这个服务了。

为新部署留预热期

不要在预热时激活eBay-killer网站。当这样的网站在官方发布时,它应该已经运行了一段时间,足以让应用服务器和数据库建立好它们的缓存,准备好所有的连接,并
完成了“预热”。

对于网站来说,可以通过金丝雀发布达到这个目标。新服务器和新的发布在开始时可以服务于一小部分请求。然后,当环境无异常并被证明行之有效后,你就可以将
更多的负载切换到这个新系统上。

许多应用程序在部署时都会急于建立内部缓存。在缓存完成之前,应用程序的响应时间往往较长,甚至可能会失败。如果应用程序行为的确如此的话,请确保在部署计划中考虑到了这件事,包括重建缓存所需的时间(
当然是在一个类生产环境中测试)。

快速失败

部署脚本也应该被纳入测试之中,以确保部署成功。这些测试也应该作为部署的一部分来运行。然而它们不应该是全面的单元测试,而是简单的冒烟测试,确保被部署的内容可以工作。

理想情况下,系统在启动初始化时也应该执行这些检查,一旦遇到了问题,就应 该让系统无法启动。

不要直接对生产环境进行修改

大多数生产环境的停机是由于那些未受控的修改。生产环境应该是被完全锁定的, 这样只有部署流水线可以对其进行改变,包括从环境配置信息到部署在其中的应用程
序和相关数据。很多组织有严格的访问管理流程。我们曾看到过,某个组织管理生产 环境访问方式是使用由审批流程和两阶段验证系统生成的有限有效期的密码,在使用
这个验证系统时需要输入一个由RSA fob产生的代码。在某个组织中,对生产系统的变 更可能只能在一个带有闭路电视监控摄像机的房间的某个终端进行操作。

这类授权过程也应该放在部署流水线中。这样做会得到相当大的好处,它意味着 有一个系统来记录对生产环境的每一次变更。没有比确切记录谁、什么时候对生产环
境做了哪些修改更好的审计跟踪方式了。而部署流水线正好提供了这种便利。

应用程序发布与部署中的几个小Tips

https://www.borgor.cn/posts/551af828.html

作者

Cyrusky

发布于

2019-07-17

更新于

2024-11-18

许可协议

评论