Zadig 跨团队之最佳使用姿势：搞定开发、测试、运维协作自动化-低调大师

Zadig 跨团队之最佳使用姿势：搞定开发、测试、运维协作自动化

2022-08-25 565

测试和验证环境作为工程师的协同平面，承担着至关重要的作用。对于多人协同的团队来说，对环境的使用和权限控制是日常工作中一个避免不了的槽点：着急发布新功能做测试验证但是只有管理员才有权限操作；一个不合时宜的发布甚至会带来生产事故让企业遭受巨大损失。不同开发者对环境和业务的熟悉程度不一样，让正确的人做正确的事；设计一个适合自己团队、基于环境权限分配的自动化协作流程，就变成一件迫在眉睫的事情。

Zadig 协作模式

Zadig 协作模式可以很好的解决上述痛点：支持对不同的工作流和环境配置不同的使用权限，批量按需赋予给团队中不同的角色成员。

下面我们以一个场景设定，来帮助大家了解 Zadig 协作模式，如何帮助团队实现权限管理、高效自动化协作的全流程。

案例场景实践

该案例场景实战讲解 Demo 项目的搭建、管理员如何配置、以及不同工程师视角的使用过程。

Demo 项目搭建

以 microservice-demo 项目为例，参考教程：如何使用 GitLab + Zadig 实现产品级持续交付
为项目配置额外的资源供使用
- 新增环境：pre-release
- 新增工作流：microservice-demo-workflow-pre-release 以上基础资源将满足从研发到交付上线的整个生命周期，以及在不同的环节团队成员的合作诉求。

一个典型的研发过程：

开发工程师：在 dev 环境进行功能开发、自测 debug、bugfix 等。日常对 dev 环境有极其频繁的变更诉求。自测完毕后，提交测试验收。
测试开发工程师：新的变更发布到 qa 环境中进行集成测试。日常对 qa 环境的鲁棒性和正确性有一定的要求。
运维工程师：负责将质量保障通过的功能灰度到 pre-release 环境（预发布环境），灰度验证无误后再全量部署到生产，对 pre-release 环境有极高的权限限制。

权限与协作需求分析

不同角色的工程师对于环境分别有不同的使用诉求和时机，而 dev / qa / pre-release 环境也分别有不同的使用目标。以下是不同角色、工作流、环境需求对照表：

如何配置协作模式

针对以上场景，描述管理员如何一步步配置协作模式

配置权限前置操作

配置协作模式前需要先把项目成员添加到项目中。

进入权限->添加成员，并赋予 project-read-only 角色。

点击项目配置中的协作模式，进入协作模式配置界面。

为不同角色配置协作模式

分别为各个角色配置不同的协作模式，根据实际需要分配工作流资源和环境资源

开发工程师对环境和工作流的使用诉求见下表：

为开发工程师配置协作模式的具体过程：

新建协作模式 dev，选择开发组成员
配置 microservice-demo-workflow-dev 工作流资源的使用权限
配置环境资源：
- dev 共享资源，可以查看、配置、管理服务实例、服务调试
- qa 共享资源，可以查看环境、管理服务实例，用于和测试(开发)工程师协同诊断问题
继续新建协作模式 dev-independent，选择开发组成员，配置独享工作流和独享环境，配置资源回收策略：30 天

根据项目需要为测试(开发)工程师、运维工程师配置相应的协作模式 qa、sre，此处不赘述。

工程师如何使用

当项目成员登录 Zadig 系统访问相应项目时，系统会为开发者分配项目资源。

开发工程师视图

工程师 flyer 访问 microservice-demo 项目，自动进入资源分配页面，点击确认
场景一：日常 bugfix，改动影响面小，风险可控，可执行工作流 microservice-demo-workflow-dev 更新共享环境 dev
场景二：新 feature 开发，暂时无法保证质量，没有信心部署到共享 dev 环境，可执行独享工作流更新独享环境进行自测 debug
场景三：当测试(开发)工程师反馈集成测试验收不符合预期，可以进入qa 环境查看，进行联合诊断

测试工程师视图

测试工程师 jody 进入该项目，进入资源分配页面，点击确认
当有业务集成测试需求时，执行工作流 microservice-demo-workflow-qa 更新 qa 环境，做集成验收

运维工程师视图

运维工程师 leo 进入该项目，进入资源分配页面，点击确认
需要灰度发布时，执行工作流 microservice-demo-workflow-pre-release 更新环境 pre-release
当开发工程师反馈 dev 环境有故障时，可对其进行诊断，协同排查；对 qa 环境的故障诊断操作也同理至此基于环境权限分配的自动化协作流程介绍完毕，每个团队需要根据自身现状设置合理的权限和资源分配策略，实现基于环境平面的高效协作。

Zadig，让工程师更专注创造。欢迎加入开源吐槽群🔥

Zadig on Github
Zadig on Gitee

微信关注我们

原文链接：https://my.oschina.net/koderover/blog/5569780

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

TAP 文章系列-12 | 小步快跑的代码扫描，实现质量左移

测试是软件质量的基础，测试左移为应用准时上线的关键在以往的日子，一个应用软件项目开发工作，相关人员无不将注意力放在范畴、预算与项目周期三个面向。而「墨菲定律」却如影随形，不断发威；我们总是无法避免的如「人月神话」书中所描述的一样陷入困境。通常，需求访谈消耗掉大量时间，大大的压缩了开发所需要的时间，即使系统设计被清楚的讨论与制订，开发者依旧被项目周期压得喘不过气来，所以测试是最常被省略的部分；一直到应用要上生产环境时，才发现应用程序没有完全实现原先设计目标，没办法满足客户要求，甚至源代码的编写或是使用的框架，都具有安全的风险，最后导致整个项目延期。即便最终，系统在跌跌撞撞的开发过程后上线，紧接的一连串Bug修正、功能增加与修改，都是是项目规划初期应该想到，却又没想到的部分。一个系统经过多年的使用与维护，历经多代轮替的开发者，早已偏离原来的设计；再加上没有良好的架构设计，也没有从项目开始时就纳入的测试，后续的开发者没有充足的信心与多余的时间进行重构，以至于整个系统的维护工作日趋沉重，也让迭代速度不断下降，整个系统也越加混乱，与热力学的熵增定律：「每个系统会从有序走向无序，日趋混乱，...

2022-08-25

452

得益于 docker 的特性，服务的创建和销毁变得非常快速、简单。Kubernetes 正是以此为基础，实现了集群规模的管理、编排方案，使应用的发布、重启、扩缩容能够自动化。本篇介绍Kubernetes的核心设计。目录 1. 编排抽象 Pod对象 Service对象 2. 声明式API 3. 开放插件总结Kubernetes核心设计主要概况为如下三点： 1. 编排抽象容器平台核心点不在于创建和调度容器，而是在上层架构抽象出各种对象，便于去统一管理。Kubernetes创造性的抽象出了各个编排的关系，例如亲密关系(Pod对象)、访问关系（Service对象）等。 Pod对象 Pod 直译是豆荚，可以把容器想像成豆荚里的豆子，把一个或多个关系紧密的豆子包在一起就是豆荚（一个 Pod）。在 k8s 中我们不会直接操作容器，而是把容器包装成 Pod 再进行管理。 Kubernetes在对象抽象方面，核心创新在于Pod对象的设计。 Pod是 Kubernetes 项目中最小的 API 对象。换句话说Pod是Kubernetes最基本的操作单元，包含一个或多个紧密相关的容器，一个Pod可以...

2022-08-26

438

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。