职场必杀技_建立一个必杀技

职场必杀技

三年前以单个ANT文件的形式开始的工作，已经成长为一百个构建任务，从开始到结束并连续运行需要八个多小时才能完成。 在本文中，我们描述了一些已应用于构建基础结构的工具和技术。

在创建构建时，我们有四个不同的目标：

• 自动化功能测试。 我们没有聘请专门的质量检查人员，并打算保持这种状态。
• 自动化的兼容性测试。 Plumbr已在100多个不同的平台上使用，因此我们需要自动创建和测试这些环境。
• 发布自动化。 我们不想在深夜里人工熬夜，以进行生产更新步骤，因此我们需要使过程中的所有过程自动化。
• 功能隔离。 我们希望将新功能与稳定的代码库隔离开来，因此我们可以隔离地测试添加的功能，并仅在成熟更改后将代码合并到稳定的代码中。

我可以说我们已经实现了这四个目标。 但这绝对不是在公园里散步-从下面的故事可以看出，所使用的大量工具和技术并不适合胆小者。

版本控制

首先，我们的源代码由Mercurial存储库支持。 新功能隔离到功能分支中，错误修正直接应用到默认分支中。 当发布版本时，我们仅在默认分支中标记相应的变更集。 我们有两个不同的Mercurial存储库-一个用于Java项目，另一个用于本机代码。

为了使文章更简单，本文的其余部分重点介绍如何构建Java项目以及如何将本机构建视为外部依赖项。

建立工件

我们的应用程序包含两个单独的构建工件

• plumbr.war –产品的用户界面，打包为标准Java EE Web应用程序
• plumbr.zip，包含两个不同的部分
  • plumbr.jar –附加到Java进程的Javaagent，负责监视性能。

工件将发布到存储库中。 我们正在为此使用Artifactory 。

构建工具

建立业务流程

在这里，我们使用Jenkins监视VCS存储库中的更改。 每当检测到新变更集时， Jenkins都会负责拉相关的变更并为变更应用所需的构建。

构建过程从构建源代码开始。 我们使用一个多项目Gradle脚本来构建Java构件（JAR和WAR）并运行单元测试。 单元测试作为TestNG测试运行。

接下来的是获取本机依赖项。 预先构建的本机是从Artifactory存储库下载的，并且在组成plumbr.zip之前，将其放置在已构建的JAR旁边。

现在，我们已经准备好将Plumbr客户端（打包为可下载的ZIP打包）和服务器（打包为WAR）发布到Artifactory。

验收建立

现在，我们在Artifactory中有可交付成果（以WAR和ZIP格式），并且我们知道单元测试已经在这些平台上通过了。 但是，由于尚未对可交付成果进行跨平台验收测试，因此我们尚无法正式投产。

为此，我们安排了每天晚上运行的Jenkins计划接受工作。 这些作业首先检查运行上一次验收测试后是否发布了新工件。 如果确实存在至少一个，则使用这些工件中的最新工件作为验收测试。

为此，我们需要基础架构。 我们需要支持不同的操作系统-Mac OS X，Linux，Windows和Solaris，因此我们需要一台支持每个构建的机器。 但是平台的复杂性并不仅限于操作系统级别。 可以将以下所有内容视为构建矩阵中的单独维度：

• 位– 32位和64位环境
• 不同的Java版本（6、7、8）
• 不同的供应商（Oracle Hotspot，Oracle jRockit，IBM，OpenJDK）。
• 不同的Java EE容器（Tomcat，Jetty，JBoss等）。

基于平台的受欢迎程度，我们到处都走了一些弯路。 但是即使采用了经过修剪的矩阵，我们也有120个不同的平台必须通过我们的验收测试。

我们使用Vagrant脚本创建测试所需的虚拟机。 这些脚本将导致虚拟机上装有OS。 接下来是Ansible剧本，将所需的JVM和应用程序服务器安装到由Vagrant创建的框中。

现在，我们已经准备好基础结构以运行验收测试。 简而言之，验收测试是一组已部署到应用服务器或以独立模式运行的应用程序。 然后将Plumbr附加到应用程序，并模拟用户以验证我们确实能够发现这些应用程序中的所有已知性能问题。

释放

验收测试成功后，我们就可以发布了。 验收测试成功完成后，我们将在LiveRebel的帮助下立即触发生产更新：

• 将新的UI重新部署为WAR文件。 这样，我们就会每晚发布一个新版本的用户界面。
• 在我们的产品中更新Plumbr客户端的每晚版本（打包为plumbr.zip）。

因此，只要夜间通过了验收测试，就会为我们的用户提供新版本的Plumbr。

结论

我们可以向您保证我们已经实现了目标。

• 每天早上7点完成更新生产，而无需任何人工干预。 当我们到达办公室时，我们可以享受生产中的新鲜版本。 或者，我不得不承认过去60天内发生过一次，请修复已损坏的内容。
• 在验收阶段，我们在120种不同的环境中进行测试。 所有这些都无需人工干预。 由于基础架构是与测试本身正交构建的，因此支持更多平台相对容易。
• 测试新功能就像在构建业务流程软件中按一个按钮一样简单，然后从头开始创建具有所有必需的基础架构和正确的应用程序版本的新环境。 产品负责人验证了交付成果后，我们将其合并回默认分支，然后由自动化部门从那里获取。
• 回归测试作为一组单元/验收测试，无需任何人工干预即可运行。

如果这一切看起来都像个必杀技，那么-确实，这是一件好事。 我们仍然有一些问题需要解决，但总的来说，我们对已经取得的成熟感到满意。 但是在您决定“是的，这就是我想要的”之前，我必须警告您-这种乐趣是有代价的。

首先，您的团队必须对技术感到满意。 流浪汉，Ansible，LiveRebel，TestNG，Gradle，Jenkins，Artifactory –实际上这只是使我们的构建保持一致的工具的子集。 当您觉得自己的团队足够成熟以应对挑战时，下一个障碍就是您需要花费大量时间。

构建基础架构本身仅需几个人月即可构建。 但是，当您要求测试本身具有足够的可靠性以拥有自动发布周期时，成本确实会增加。 这是需要大量投资的事情。 截至目前，我们将工程时间的20％用于创建和维护测试。 而且我可以保证，尤其是在开始时，它看起来并没有花费很长时间。 另一方面，如果您检查我们所取得的成就，也许可以考虑一下……

翻译自: https://www.javacodegeeks.com/2014/04/building-a-nirvana.html

职场必杀技