标签：linux testing windows deployment build-process

作为经常在QA,构建和操作之间切换的人,我一直在讨论如何在构建服务器上进行操作系统更新. Windows,Linux,MacOS或任何其他可以通过互联网更新自己的o / s的二分法是相同的：

> QA团队希望保持构建服务器从产品发布周期开始到结束,因为安装更新可能会破坏服务器的稳定性,并且意味着不会针对相同的基线进行连续构建.
>运营团队希望将软件部署在具有所有最新安全补丁的系统上;这可能意味着该软件未部署在与其构建的完全相同的o / s版本上.

我通常通过获取候选版本并将其安装在具有完全最新o / s的测试服务器上来重复此操作,重复在构建服务器上运行的自动化测试并进行一些额外的系统级测试以确保部署之前一切都很好看.然而,这对我来说似乎效率低下;有没有人有更好的方法？

解决方法:

我个人认为你在这里没有太多问题 – 只需将最新的更新应用到构建服务器.我这说的主要原因是：

>您的代码或构建服务器上的任何依赖项与操作系统版本紧密耦合的可能性很小,以至于安装常规更新会影响任何事情,更不用说打破它了. Windows版本之间的窗口消息等之间可能存在细微差别,但这些差异很小,而且通常在互联网上有很好的文档记录.如果您使用的是托管技术堆栈,如WPF / Silverlight或ASP.Net,甚至大多数是Winforms,那么您将与这些更改隔离 – 如果您正在使用WinAPI直接创建窗口或绘制您的硬核内容,它们应该只会影响您纽扣.
>总是根据最新版本的操作系统设计您的产品是一种很好的做法,因为您需要鼓励您的客户实施这些更新 – 如果您不应该对您的客户说不要安装更新xyz,因为您的应用程序不会针对它运行 – 特别是如果该更新是关键的安全更新
>测试OS版本之间的差异应该由QA团队完成,并且应该独立于构建服务器上的内容
>您不希望您的构建服务器进入这样一种状态,即它与公司更新过程如此隔离,以至于当您最终将它们全部应用到barfs并随处吐出熔化的硅时. IOW,等待更新的时间越长,出现问题的风险就越大,灾难性地发生.小而频繁/增量更新的风险低于每十年一次的大规模更新:)

构建服务器更新您必须谨慎对待第三方控件或库更新 – 它们通常可能包含重大更改或显着更改的行为.他们确实应该安排,然后进行一轮测试,寻找任何变化.

标签：linux,testing,windows,deployment,build-process
来源： https://codeday.me/bug/20190827/1740796.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。