“功能分支的优势在于&＃xff0c;每个开发人员都可以使用自己的功能&＃xff0c;并且不受其他地方进行的更改的影响。” &＃xff08; FeatureBranch &＃xff09;
Feature分支已经存在很长时间了&＃xff0c;并且是开发团队中的常见做法。 没有他们&＃xff0c;我无法想象一个团队的发展。 如果有人要我与正在使用其他功能的同事共享分支机构&＃xff0c;这似乎很荒谬。 只是这个想法让我不舒服。 很容易看出&＃xff0c;功能分支提供的隔离也是测试应用程序所需要的。 更具体地说-测试其集成。
保持运行代码隔离非常容易&＃xff0c;您可以在本地运行所有代码。 我已经在几乎所有使用过的计算机上安装了MySQL和Redis。 但是&＃xff0c;随着我们的应用程序逐渐依赖于托管服务&＃xff08;例如Cognito和BigQuery&＃xff09;&＃xff0c;在本地运行100&＃xff05;成为一个问题。 可以模拟或模仿这些服务&＃xff0c;但它们的行为绝不会像原始服务那样。 此外&＃xff0c;应经常且早地测试这些集成&＃xff0c;因为应用程序的边界往往是我们感到惊讶的地方&＃xff0c;也是事情破裂的地方 。
营救环境
因此&＃xff0c;如果我们要针对真实的云服务测试应用程序&＃xff0c;为什么我们不能共享&＃xff1f;
实际上这在小范围内有效。 例如&＃xff0c;每个开发人员都在本地运行其代码&＃xff0c;每个人都使用专用的S3存储桶&＃xff0c;该存储桶具有不同的文件夹以隔离使用情况。 但是您不必费神就可以打破这种局面。 如果我们正在使用SQS队列怎么办&＃xff1f; 我的本地应用程序会将消息推送到该队列中&＃xff0c;而只是让同事的本地应用程序提取该消息。 这正是我们要避免的中断类型。 我们每个人都应该使用自己的队列&＃xff0c;并从那里推断我们自己的环境 。
首先&＃xff0c;为每个功能分支或每个拉取请求运行环境都取决于您如何感知CD管道。 不要把它想成“ 这个部署 环境 ”&＃xff0c;但“ 本次部署 的 环境 ”。 您只需要给它起一个名字即可。 这可能是“ 生产 ”或“ 登台 ”&＃xff0c;但也可能是“ 功能蓝色按钮 ”的“ pr1017 ”。 您的CD流程需要适用于现有环境以及新环境。 这就是Terraform真正的光芒所在。
因为Terraform使用声明性方法&＃xff0c;所以它负责确定环境是新环境还是需要创建&＃xff0c;或者环境是否存在并且需要更新。 Terraform的另一个关键功能是工作区 &＃xff0c;它可以隔离不同环境之间的状态&＃xff08;在以前的版本中甚至称为“环境”&＃xff09;。 您的Terraform代码将需要使用变量$ {terraform.workspace}&＃xff0c;以确保您的资源专用于您所处的环境。
一个有效的例子。
我们将使用一个非常简单的设置进行工作&＃xff0c;以说明此流程。 我们将从一个S3存储桶开始&＃xff0c;该存储桶作为网站公开&＃xff0c;其中包含一个简单的HTML文件&＃xff1a;
locals {environment_name &＃61; terraform.workspace
}
resource “aws_s3_bucket” “website_bucket” {bucket &＃61; “ ${local.environment_name} .feature.environment.blog.com”acl &＃61; “public-read”force_destroy &＃61; truewebsite {index_document &＃61; “index.html”}
}
请注意&＃xff0c;我们如何从Terraform工作空间名称创建本地变量&＃xff0c;并使用该变量为存储桶赋予每个环境唯一的名称。
我们的“ CD进程”将是一个简单的bash文件&＃xff0c;它接受环境名称作为参数&＃xff1a;
echo “Deploying environment $ENVIRONMENT ”
echo “Injecting env vars”
sed ‘s/!!!ENVIRONMENT!!!/’” $ENVIRONMENT ”’/g’ index.template.html > $ENVIRONMENT .index.html
echo “Applying Terraform”
terraform init
echo “Selecting/creating workspace”
terraform workspace select $ENVIRONMENT || terraform workspace new $ENVIRONMENT
terraform apply
在这里&＃xff0c;我们 -
- 将环境名称注入到html文件中&＃xff0c;该文件将用作我们的静态站点。
- 选择/创建一个以我们的环境命名的Terraform工作空间。
- 应用环境。
&＃xff08;您可以在 https://github.com/env0/feature-environments-blog-code中 找到完整的示例 &＃xff09;
让我们运行它&＃xff01;
运行./apply.sh env1将部署一个名为env1的环境。 Terraform将初始化&＃xff0c;向我们展示将要执行的操作&＃xff08;Terraform计划&＃xff09;&＃xff0c;并且在部署所有内容之后&＃xff0c;将输出网站的端点。 如果我们进入该网站-我们会看到类似的内容-
让我们尝试再次运行该命令&＃xff0c;这次是针对另一个环境。 我们将运行./apply.sh my-other-env &＃xff0c;我们将获得一个指向如下所示网站的链接&＃xff1a;
更新中
为了更新我们的环境&＃xff0c;我们要做的就是再次使用相同的环境名称运行apply.sh。 我们的代码和Terraform将认识到我们正在现有的环境中工作&＃xff0c;并将相应地对其进行更新。
毁灭
当分支被合并和删除时&＃xff0c;就不需要这种环境了&＃xff0c;我们绝对不想继续为此付费。 为了破坏该特定环境&＃xff0c;我们只需要运行-
> terraform workspace select $ENVIRONMENT
> terraform destroy
Terraform将请求批准&＃xff0c;然后从那里获得批准。 不过要小心&＃xff0c;因为这些猫的照片不容易找到&＃xff1b;&＃xff09;
自动化
拥有要素环境的下一步也是最后一步&＃xff0c;就是使它们自动化。 这是非常有益的自动化操作&＃xff0c;您的工程师将感谢您为他们打开的每个分支/ PR都获得专用的隔离环境。 您可以获取上面显示的apply.sh文件的某个版本&＃xff0c;并将其放入管道中&＃xff08;GH操作&＃xff0c;Circle&＃xff0c;Jenkins等&＃xff09;。 只要确保您还记得分支/ PR关闭时的销毁部分即可。
功能环境的乐趣
从env0开始 &＃xff0c;我们从第一天开始就使用功能环境。 我们打开的每个PR都运行自己的环境。 这确实有助于我们尽早且不间断地测试我们的整个应用程序。 我们通常也使用它来展示开发中的功能&＃xff0c;这确实有助于早日获得反馈。 这也是在开发过程的早期开放PR的另一个诱因&＃xff0c;这是分享我们正在从事的工作的好方法。 每个开发人员每个月运行大约20个环境&＃xff0c;平均环境寿命约为1.5天。
从博客文章到现实世界
我想请您对上述所有内容一视同仁-此代码实际上是一个过于简化的示例&＃xff0c;旨在说明工作流程。 随着软件的发展&＃xff0c;使它“在野外”运行通常要复杂得多。 使Terraform自动化和管理云环境并不是一件容易的事&＃xff0c;并且大多数CI / CD工具都可以运行一次任务&＃xff0c;而不是管理生命周期更长的“环境”。
这就是为什么我们创建了env0 &＃xff08;一个完整的环境即服务解决方案&＃xff09;的原因&＃xff0c;该解决方案旨在为您的开发人员提供他们所需的动态基础架构&＃xff0c;而不会损害组织控制和管理云资源使用方式的需求。 请访问www.env0.com 。
下一步 -
正如我上面所写的那样&＃xff0c;功能完善的环境很少像上面的示例那样简单。 所以在这一点上&＃xff0c;您可能会问各种各样的问题-
- 听起来很贵&＃xff01; 有什么方法可以使其更便宜&＃xff1f;
- 让每个人都可以访问部署基础架构可能会变得混乱—如何控制我的云使用量&＃xff1f;
- 我已经有Terraform代码-但它运行静态环境。 使它动态化的步骤是什么&＃xff1f;
如果您想进一步了解上述内容&＃xff0c;请在评论中让我知道&＃xff0c;我将尝试写一篇后续文章。
谢谢阅读&＃xff01;
先前发布在https://medium.com/env0/from-feature-branches-to-feature-environments-with-terraform-652c0fdf0e78
From: https://hackernoon.com/from-feature-branches-to-feature-environments-with-terraform-10973ycb
京公网安备 11010802041100号