预算内的软件自动化

最新推荐文章于 2024-09-15 01:19:00 发布

danpu0978

最新推荐文章于 2024-09-15 01:19:00 发布

阅读量101

点赞数

文章标签：大数据编程语言数据库 python linux

当一家企业起步或启动一家初创公司时，可以理解的是，资金将紧缺，现金流几乎不存在。准备业务的核心产品以及其营销策略和其他核心业务功能时，存在明显的紧迫感，而不是专注于理想的自动化解决方案。

与验证服务产品，赢得新客户或进行销售没有直接关系的任何事情都可以推迟到未来某个阶段。鉴于不能保证企业的成功，很容易看出长期思考是一种可选的额外手段，甚至是奢侈；当企业获得一定程度的确定性和可预测性时，需要等待一段时间。有很多事情可以归为此类，其中之一就是软件自动化。

但是，如果企业对长期成功具有强烈的渴望，则需要考虑那些可降低成本和支出的活动，例如软件自动化。虽然在引导阶段保持更多的短期关注很重要，但是企业必须考虑处理长期成本。

因此，从一开始就应该考虑周全的软件自动化解决方案。这导致我们提出两个核心问题：

我们如何创建一个一开始就易于实施的解决方案，同时又可以随着业务需求的变化和增长而扩展？
我们如何建立与我们的可用时间和业务发展阶段成比例的投资解决方案？

这些问题不容易回答，因此让我们研究一系列潜在的解决方案以找出答案。但是在我们这样做之前，重要的是要认识到并非所有业务都是相同的，尤其是在技术领域。

在本文中，我将基于一个假设的业务发布解决方案，该业务发布了一个在线视频培训网站，人们可以在该网站上登录并购买他们感兴趣的课程。假设该网站是用一种现代的，动态的语言（例如PHP，Python或Ruby）编写的。我们还假设它使用了一种更流行JavaScript前端之一，例如AngularJS ， Ember.js或Backbone.js 。

我本来可以提出一种更为复杂的体系结构，但让我们继续关注自动化解决方案的讨论，而不是产品或服务。

自动化解决方案易于实施吗？

对于一个开发团队而言，简单的工作可能是对下一个开发人员的挑战。话虽这么说，让我们考虑一些更简单的解决方案。

部署自动化解决方案可能涉及什么？好吧，您可能将具有以下组件：

服务器配置：是否需要安装，停止，启动或重新启动新服务？
数据库迁移：是否需要运行数据库迁移来更新架构（可能是代码更改的结果）？
代码部署：是否有新的代码更改需要推出，无论是测试，登台，上线还是其他环境？
缓存清除：是否需要刷新缓存目录或服务？
身份验证凭据 ：需要哪些服务或服务器？这些详细信息可以直接在配置文件中提供，也可以从服务器环境中提取。
版本控制 ：哪个系统管理代码？我假设所有源代码都由Git版本控制。

这些是我认为要管理的自动化流程的最低要求。现在让我们讨论如何实现这样的过程。

基本的软件自动化解决方案

我已经多次说过计算机是为自动化而设计的。人类不是。我们会在最佳时机犯错，更不用说在压力，疲劳或情绪分散的时候了。因此，第一件事是确保我们的自动化解决方案可编写脚本，以便每次都以相同的方式重复该过程。

让我们从用Perl或由Git钩子启动的许多Linux shell（例如Bash或ZSH）之一编写的解决方案开始。

在标记了发行版之后，Git挂钩将启动我们的测试套件，如果测试通过，则将启动我们的自动化脚本。然后，将使用以下命令，在我们的标记和上一个标记之间查找更改的文件，从而为我们提供要部署的文件列表。

PREV_TAG=$(git rev-list -n 1 0.13.0)
LATEST_TAG=$(git rev-list -n 1 0.14.0)
git diff --name-status $PREV_TAG..$LATEST_TAG | awk '{print $2}'

然后可以使用SCP ， SFTP或SSH上的Rsync等标准工具将返回的文件列表部署到测试服务器。

完成后，该脚本可以调用远程脚本来清除远程服务器上的缓存目录，运行任何数据库迁移脚本并更改测试服务器上的程序包。

作为附加的完整性要求，我们可以让脚本要求输入用户名或密码，以用于标识运行脚本的用户。或者，它可以使用操作系统级别的技术（例如whomami或服务（例如LDAP）来标识当前登录的用户。

积极因素

让我们考虑一下使用此基本软件自动化解决方案已实现的目标。我们创建了一个本地化的，自动化的，可重复的解决方案，其中包含了我们在本文前面列出的七个核心要求。

部署的文件仅是Git标识为已更改的文件。如果出现问题（例如创建新的错误），我们可以快速跟踪它的来源以及谁运行了最后一个部署。不论谁运行，它都可以在任何时间，白天或晚上以相同的结果运行。

最后，由于它是用Linux shell或Perl编写的，因此有大量潜在的开发人员可以维护它。

底片

尽管这应该相对较快地进行设置，但是它会创建一个新的代码库，从而又需要维护。它可能会或可能不会在业务所需的尽可能多的服务器上扩展，至少没有没有足够的重构或开销。它还可能具有性能或安全缺陷。

然后就是开发和维护解决方案的成本。内部开发完整的解决方案是否从头开始具有成本效益？

这种方法不需要外部服务或软件的进一步费用。但是，开发人员的时间费用呢？可以说，当您的开发人员应该专注于开发公司的产品或服务时，这比外部服务或其他软件的费用要高得多。

那么，对于更成熟，更可重用且对开发人员时间要求不高的东西呢？

改善配置并简化部署

让我们重构解决方案并解决原始版本的一些缺点。让我们从使用开源解决方案（例如Ansible ， Chef或Puppet）替换负责服务器供应的脚本组件开始。

所有这些都是独立开发和维护的工具，并且具有适用于各种情况的大型第三方软件包添加库。它们都是众所周知的解决方案，具有大量的在线文档，在全球范围内举行经过认证的培训课程，并且在整个行业中得到使用。

该代码使用标准约定和符号，以使其井井有条，可版本控制和易于理解。无论我们要管理几百台还是几百台服务器，这些解决方案中的任何一个都比我们自己开发的解决方案更容易开发和扩展。

鉴于这些工具几乎是事实上的性质，找到有经验的开发人员来维护我们的代码也将更加容易。

现在让我们进行代码部署。一种解决方案是在远程服务器上具有裸露的Git目录，以及源代码的克隆。在这种情况下，测试通过后，无需查找要同步的文件列表，而是将其推送到远程裸机存储库，该存储库随后将处理更新远程部署目录。

过去，我曾在小型应用程序中使用过它，而且效果很好。无需编写额外的脚本，也不必担心文件可能会被忽略，权限不正确等等。但是，它缺少一些关键考虑因素，例如能够回滚到以前的版本或管理相关过程，例如数据库迁移或缓存清除。

因此，让我们看看其他解决方案来填补空白。很高兴地提供了一系列工具。其中包括Deployer ， Capistrano和Mina 。

无论哪种语言，它们都是可配置的解决方案，可以在发行版中部署代码，并支持回滚到先前发行版，管理固定发行版数，执行角色过滤，主机过滤等功能。而且，它们既提供了预制部署任务的预设列表，又允许创建自定义任务。它们还可以与特定于语言的工具集成，例如Composer for PHP，该工具可以执行相关任务，例如数据库迁移脚本。

创建完成后，再次使用定义的文档，部署代码更改可以像运行脚本一样简单，例如deploy <deployment environment> 。每次都以相同的方式处理一切。