2016 “Better Software East/DevOps East/Agile Dev East”三个会议上的发言

在佛罗里达州举行的“BetterSoftwareEast/DevOpsEast/AgileDevEast”会议上,测试成为焦点议题之一,约四分之一的演讲围绕测试展开。会议强调了测试人员角色的变化及其在DevOps背景下的新职责。同时,沟通也是重要议题,ChatOps实践被提出以提高团队沟通效率。

Better Software East/DevOps East/Agile Dev East”三个会议的第三和第四天会议在佛罗里达州的奥兰多举行。会议延续了前两个会议建立起来的趋势,发言涉及内容非常广泛,但测试是非常明确的重点内容。第一天和第二天的会议议程主要为半天或一天的导师授课,第三和第四天主要为限时一个小时的发言。

\\

在三次会议安排的64次发言中,15次发言——几乎占总发言量的四分之一——与测试主题有关。在这些发言中,多数都在探讨在DevOps的背景下测试人员可以起到的作用、物联网、以及不断增长的将指标用于决策的趋势。虽然话题在不同发言中会有所不同,但其中大部分都是基于以下的核心思想,就是一方面传统上的由测试人员进行的许多活动都将不再存在(比如手动执行测试脚本),但另一方面他们可以站在不同的角度考虑问题,这一点仍然可以得到很好的利用。因此,大多数关于测试的发言都没怎么谈到工具和技术,而是专注于如何在公司内配置测试人员。不过有一个发言例外,就是Alexander Andelkovic的发言:“测试中的人工智能:未来就是现在”。在发言中,他描述了在游戏开发商King里人们是如何训练不同的机器人去模仿人的动作,通过这样的方式测试游戏的难度级别的,比如Candy Crash Saga等。

\\

除了测试,沟通是下一个最有争议的话题,值得单独一提的是自然出现的ChatOps的实践。ChatOps的基本思路是通过将尽可能多的工作集中到即时通讯应用中,以此更好地将工作和沟通结合起来。使用传统的IM工具是不可能实现这一点的,但像HipChat或Slack等更现代工具却把这个概念最基础的三个特征体现了出来:自由创造公共和私人渠道的能力;整合第三方工具使之可以像其他用户那样将信息写入聊天室的能力;还有最重要的能力是,要嵌入聊天机器人,可以对某些命令做出响应。

\\

正如Raj Indugula和Robert Brown说到的,理解从第三方工具得到的通知的关键是,这些通知往往具有重要的同步属性:它们通常要求得到立即的回应。例如,从持续集成服务器来了通知,显示构建失败了,这就是开发人员需要马上检查的事情。然而,在传统上通知常被配置为通过电子邮件发送,这是一个相当异步的通信机制。这就经常导致事件无法被快速处理,并且过期的通知还污染了人们的收件箱。因此,将这种类型的通知发送到一个即时通讯工具中是一个更好的解决方案,这样开发人员就能够采取更快速的行动,然后信息就可以滚屏上去,并被忽略。这样也有风险,过多的通知会在聊天室中产生过多的噪音,这就是为什么需要创建多个渠道,并需要将这些通知相应地发送到相关渠道去,这样的能力变得非常重要。

\\

但Indugula和Brown展示出的最具革命性的能力是使用聊天机器人控制外部系统,而无需离开IM工具。他们的发言中提到了在线看板工具Trello的例子。Trello和Slack的结合产生了一个聊天机器人,它可以在Slack里面操作Trello中的不同卡片,只要把留言板作为一个命令行来使用。这样,通过键入 “/trello add New Task”,Trello聊天机器人就会连接到Trello实例中,并创建一个名为“New Task”的新卡片。这意味着团队成员现在可以用IM工具管理自己的任务了,而且可以快速地通过使用“/hangout”命令,在家启动与整个团队的视频会议,还有管理从GitHub来的pull请求等等。可能整合的列表在不断变长,可以在Slack的应用程序目录下或者HipChat的Atlassian Marketplace中找到这个名单。

\\

总之,从“Better Software East/DevOps East/Agile Dev East”三个会议中得出的主要结论之一就是,各个公司在他们进行文化转换的时候将继续寻找传统角色的适应方法,尤其是测试人员将会不得不改变,在新的活动中重新使用技能。另一个主要结论是,沟通管理仍然是许多团队的痛点,这将推动创建新的工具,用更加有效的方式来帮助过滤、分发和共享信息。

\\

查看英文原文Talks at Better Software East / DevOps East / Agile Dev East 2016

<think>嗯,用户这次给了一个看起来像是配置文件的路径,可能是在Ansible中设置角色和集合的路径。我需要先理解这两行注释的作用。用户可能在使用Ansible时遇到了路径配置的问题,或者想了解如何正确设置这些路径。 首先,用户给出的两行都是注释,以#开头,所以实际可能不会生效。需要告诉用户如何正确配置ansible.cfg文件中的roles_path和collections_path。可能用户是刚接触Ansible,不太清楚如何配置环境,导致角色或集合找不到。 然后,要解释每个参数的作用。roles_path指定Ansible查找角色的目录,而collections_path则是集合的安装位置。需要说明默认路径和自定义路径的区别,以及为何要修改这些路径。例如,团队协作时统一路径,或者项目需要特定位置的依赖。 接下来,要给出正确的配置示例,去掉注释符号,并指导用户如何验证配置是否生效。比如通过ansible-config dump命令检查当前配置,或者在playbook中运行测试任务。 还要注意可能的陷阱,比如路径权限问题,或者多个路径的设置方式。比如roles_path可以包含多个目录,用冒号分隔,这样Ansible会按顺序查找。同时,需要提醒用户,修改路径后可能需要重新安装角色或集合到新位置,否则会找不到。 用户可能是在尝试自定义Ansible环境,但不知道如何正确修改配置文件,或者遇到了路径配置错误导致任务失败的情况。因此,回答要详细说明每一步,并给出实际例子,帮助用户理解和应用。 最后,确保语言简洁明了,结构清晰,分点说明,让用户能一步步按照指导操作,避免混淆。同时,补充注意事项,帮助用户避免常见错误,比如注释符号的问题和路径分隔符的正确使用。</think>以下是关于 `#roles_path` 和 `#collections_path` 配置行的详细说明: --- ### 一、配置行含义 1. **`#roles_path=/home/devops/ansible/roles`** - **作用**:定义 Ansible **角色(Roles)** 的默认搜索路径 - **当前状态**:以 `#` 开头表示注释(未生效) - **默认值**:若未配置,Ansible 默认在以下位置查找角色: - 当前项目目录下的 `roles/` - `~/.ansible/roles/` - `/usr/share/ansible/roles/` - `/etc/ansible/roles/` 2. **`#collections_path=/home/devops/ansible/mycollections`** - **作用**:定义 Ansible **集合(Collections)** 的安装目录 - **当前状态**:注释未生效 - **默认值**:未配置时,集合默认安装在 `~/.ansible/collections/` --- ### 二、启用配置的步骤 1. **修改 `ansible.cfg` 文件** 在 Ansible 配置文件(通常位于 `/etc/ansible/ansible.cfg` 或项目目录中)**取消注释并修改路径**: ```ini [defaults] roles_path = /home/devops/ansible/roles collections_path = /home/devops/ansible/mycollections ``` 2. **多路径配置(可选)** 若需指定多个搜索路径,用冒号 `:` 分隔(Linux/macOS)或分号 `;` 分隔(Windows): ```ini roles_path = /path1/roles:/path2/roles ``` --- ### 三、验证配置是否生效 1. **通过命令行检查** ```bash ansible-config dump | grep -E 'roles_path|collections_path' ``` 输出应显示已配置的路径: ``` COLLECTIONS_PATHS(default) = ['/home/devops/ansible/mycollections'] DEFAULT_ROLES_PATH(default) = ['/home/devops/ansible/roles'] ``` 2. **实际操作验证** - **角色查找**:运行包含角色的 Playbook,检查是否自动从新路径加载角色 - **集合安装**:执行 `ansible-galaxy collection install` 后,确认集合安装到指定目录 --- ### 四、典型应用场景 1. **团队协作** 统一角色和集合的存储路径,确保多环境配置一致性 ```ini # 示例:共享 NAS 存储路径 roles_path = /mnt/nas/ansible/shared_roles ``` 2. **隔离开发环境** 为不同项目指定独立的依赖目录 ```ini # 项目 A 专用配置 roles_path = ./project_a_roles collections_path = ./project_a_collections ``` --- ### 五、注意事项 1. **路径权限** - 确保 Ansible 运行用户(如 `devops`)对配置路径有读写权限 - 示例授权命令: ```bash sudo chown -R devops:devops /home/devops/ansible ``` 2. **路径优先级** - 命令行参数 `--roles-path` 优先级高于配置文件 - 环境变量 `ANSIBLE_ROLES_PATH` 优先级最高 3. **依赖管理** - 修改 `collections_path` 后,已安装的集合**不会自动迁移**,需重新安装 - 建议通过 `requirements.yml` 文件管理依赖: ```bash ansible-galaxy install -r requirements.yml -p /home/devops/ansible/mycollections ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值