Environment(环境)标签页
过渡到更加模块化的用户界面使我们能够在清晰紧凑的空间中容纳功能。 已经有150个操作涵盖了大部分DevOps领域，我们决定给用户完全的自由，让他们能够完全自定义自己的的操作。当然，这并不意味着我们不会再添加新操作——远非如此。我们只想给您提供更好的DevOps服务。😎
自定义操作是存储在存储仓中的特殊YAML文件定义。您需要做的就是将操作的定义和图标推送到默认分支，一旦成功解析，该操作就会光彩夺目地出现在您的操作列表的顶部，标签页像您的新设计徽章一样闪闪发光 ，显示的是您自己自定义图标，同时您可以大声地告诉别人：“看，这是我设计的”。您可以自由添加任意数量的选项卡和输入，自定义图片、命令和标签，并根据您的工作流程所需调整操作。
name: "My_Ping_Action"
inputs:
ip:
required: true
count:
default: '1'
execute_commands:
- ping $ip -c $count
docker_image_name: "node"
docker_image_tag: "16"
count)设置为1$ip和$count一旦添加到存储库中，操作就会从上到下呈现到GUI中：
在这里我们可以在操作日志中看到执行结果。 一切正常！
这是一个更真实的例子。假设您的团队正在使用像Asana这样的任务管理系统。目标是在重要流水线失败时通过在Asana中发布带有失败执行链接的任务来通知您的团队。
通常，它需要在Asana的API中运行一个带有curl的方法。但是，此解决方案的缺点是您需要在本地Shell或自定义构建等操作中定义API调用，并且每当Asana端发生更改时，脚本就会停止工作并需要手动更新。因此，您只需要定义一个将在Asana中发布任务的操作，并在整个工作区中使用即可。
name: "new_task"
inputs:
title:
type: TEXT
default: "title"
assignee:
type: SELECT
required: true
options:
- "Alexander"
- "Mike"
- "Anna"
- "John"
content:
type: TEXTAREA
required: true
execute_commands:
- run docker asana_custom
docker_image_name: "my_company/asana_custom"
docker_image_tag: "latest"
tabs:
projects:
name:
type: SELECT
required: true
options:
- "Project-1"
- "Project-2"
- "Project-3"
- "Project-4"
在上面的例子中，调用Asana API已经被包含在了从中启动操作的Docker镜像中。
Buddy的驱动方式100%为客户。如果有需求，请告诉我们您需要哪些集成才能将您的DevOps自动化提升到更高的一个级别！要是您在Buddy系统使用上缺失了一些必要的功能，请直接联系我们以获取更好的技术支持：support@buddy.red
此功能目前处于测试阶段，仅包含基本通讯功能。请告诉我们如何扩展令其更好用！
将消息传递给团队中的每个人对于开展业务至关重要，尤其是在与喜欢为每个遇到的问题(包括消息传递服务)使用独立工具的开发人员合作时。为了帮助经理们处理这个问题，我们添加了一个应用，用于在Buddy中发送应用内消息。
此功能可以由有权访问“工作区设置”导航菜单的任何用户发送，点击“工作区设置”进入可见如下图所示：
单击 + 按钮将启动一个窗口，您可以在其中撰写消息。消息正文支持Markdown格式，如果需要，可以随意添加链接、粗体、表情符号👻和代码：
要在行与行之间添加<br>换行，如上图请使用反斜杠"\"
若要在发送之前查看消息显示效果如何，请单击“预览”按钮：
单击“添加通知”将发布消息，并在浏览器刷新时将其显示给所选用户。该消息将保持打开状态，直到用户手动将其关闭。您可以在底部的最后选项中设置到期日期：
颜色编码可让您明示通知的重要性。只是不要把所有通知都涂成红色，否则您的团队很快就会习惯，并快速关闭您的消息而不阅读！😉
Buddy是100%客户驱动！告诉我们您需要哪些集成才能将您的自动化开发运维提升到一个新的水平！如果您错过了某个功能或集成，请在客服聊天与我们联系，或者直接给我们发邮件：support@buddy.red
通往自动化天花板的道路崎岖不平，有时需要回溯才能保持在正确的轨道上。 对于我们的UI来说尤其如此，它使Buddy在CI/CD在竞争激烈的行业市场上如此独特。 因此，我们在添加和管理操作时为流水线提供了额外的优质体验，以提高整体可用性 - 并恢复了您想要的特色功能。
为更清晰明了，列表中的操作已分成不同的操作反馈标签页：
添加动作现在也更容易了。您可以像以前一样单击 + 按钮并在操作列表中查找操作，或者单击 ⋮ 在不离开流水线视图的情况下输入操作名称：
另一方面，操作右侧的⋮按钮也扩展了一个下拉菜单，您可以在其中复制、删除操作，或与下一个操作 并行/取消并行(对于加速测试方面有用)：
操作环境管理上添加了漂亮的On/Off(开启/关闭)按钮，让您更方便地在流水线上顺手打开或关闭某个流水线操作环节。
凭借其简单的语法，Terraform允许在每个云服务中轻松供配、更改与操纵版本资源。Terraform成为最受欢迎的IaC(基础设施即代码)的工具之一，难怪它很快就成为Buddy最需要的功能之一。今天，终于来啦！
除了部署代码外，Terraform还允许用户自动化基础设施更改。Terraform配置保存在存储仓中，从而可以进行版本控制。根据代码中包含的要求调整我们的基础架构，交付流水线将自动运行“terraform apply”。
Terraform配置文件(.tf)中描述了基础架构。首次运行“Terraform”将创建所描述的资源。除此之外，将创建一种称为Terraform状态(State)将用作连续运行的数据库。
Terraform状态对整个过程至关重要，因为它让我们清楚接下来在“terraform apply”执行中我们做的事。
示例:
请确保Terraform状态为持续有效。如果没有，Terraform将在每次连续运行时创建一个新的基础架构，而不是更新已经存在的基础架构！
为了维护您的状态，建议使用称为Terraform后端(Backend)的东西。而我们建议使用AWS S3或Google GCS。
您可以在我们的交付流水线中使用Terraform CLI操作。它允许您提供将在包含“.tf”文件的存储仓相关联工件中执行命令，同时还允许您选择Terraform版本。
我们建议使用固定的Terraform版本而不是最新版本“latest”。以前曾有过因为不同版本的Terraform状态而导致出现问题的情况。使用固定版本可以让您更好地控制并防止更改更新时出错。
Terraform后端配置可以直接在存储仓中的“.tf”文件中完成，也可以使用操作的“变量”选项卡中设置的环境变量来完成。除此之外，Buddy提供专用的AWS和GCP集成，允许在S3/DynamoDB和谷歌云存储中进一步后端配置选项。
以上流水线是使用Terraform的示例之一。构建应用程序后，Terraform将验证配置文件是否正确。如果一切顺利，则以下变更集条件Terraform操作将计划更改，这些更改将在手动批准后执行。在这个场景中，我们使用Rsync作为部署操作示例。
为确保基础架构更改仅在“*.tf”文件发生更改时触发，我们在操作2-6中添加了触发条件。这样，只要没有基础架构更改，流水线就会正常构建和部署您的应用程序。
参看: