首页 文章 精选 留言 我的

精选列表

搜索[AI产设研一体],共10000篇文章
优秀的个人博客,低调大师

Nitrux 2.7 发布,发布自研 Maui Shell & Maui Apps

Nitrux 是一个基于 Debian 的 Linux 桌面发行版。它使用 Calamares 安装程序,包括建立在 KDE Plasma 5 桌面环境上的 NX 桌面和 MauiKit 应用程序。Nitrux 也不使用 systemd 作为它的启动系统;相反,它使用 OpenRC。 Nitrux 2.7 由 Linux 6.1 LTS 内核系列提供支持, 这个版本首次发布专门用于演示 Maui Shell 和 Maui Apps 的 ISO ,Maui Shell 是由 Nitrux 开发团队开发的用于桌面和移动设备的融合桌面界面。 它有一组使用 Maui Kit 创建的内部应用程序,称为 Maui Apps(也可在 KDE Plasma 版本中使用)。: Maui 应用程序列表包括以下内容: Agenda、Arca、Bonsai、Booth、Buho、Clip、Communicator、Fiery、Index、Maui Manager、Nota、Pix、Shelf、Station、Strike 和 VVave。 官方建议在物理硬件上使用 Maui Shell 测试 ISO,不要在 VM 中使用此 ISO。 其他软件层面的更新: KDE Plasma 升级到 5.27.2 版,KDE Frameworks 升级到 5.103.0 版, KDE Gear 升级到 22.12.3 版。 Firefox 版本 110.0.1。 将 MESA 更新到版本 23.1~git2303050600.af9536~oibaf~l 添加了 OpenVPN。 添加了 open-iscsi。 将 Nvidia 专有驱动程序更新至版本 525.89.02。 更多详情可查看官方的公告:https://nxos.org/changelog/release-announcement-nitrux-2-7-0/ 下载地址: ISO—Direct HTTP Download from our server. FOSS Torrents (Torrent). Sourceforge (mirror). OSDN (mirror).

优秀的个人博客,低调大师

vivo 自研Jenkins资源调度系统设计与实践

作者:vivo 互联网服务器团队- Wu Qinghua 本文从目前业界实现Jenkins的高可用的实现方案,分析各方案的优缺点,引入vivo目前使用的Jenkins高可用方案,以及目前Jenkins资源的调度方案的设计实践和目前的落地运行效果。 一、前言 现在的企业很多都在用Jenkins做持续集成,各个业务端都依靠Jenkins,vivo Devops也是使用Jenkins来进行持续构建,部署Jenkins服务时如何保障服务的高可用变得尤为重要。 下面是目前Jenkins存在的一些问题。 Jenkins本身是单体的,即只能有一个Jenkins Master。虽然你也可以在多台机器上部署多个Jenkins Master,但这些Master之间没有联系,都是各自把任务交给手下的slaver去执行,没有任何交集。也许某个master下的slaver很忙,而另一个master下的slaver却很闲,资源得不到充分利用。 当其中一个slave宕机之后,该slave上的运行的job任务没有版本重新进行分配,需要用户重新执行。并且slave节点离线之后没有通知管理员。 当系统业务量比较大的时候业务请求集中在Jenkins Master上,会对Jenkins造成压力,甚至的造成Jenkins服务不可用。 当有job任务在jenkins Master上队列排队的时候,Jenkins Master宕机后,队列任务不可持久化。 Jenkins Workspace没有自动清理功能,会导致磁盘空间不足,任务执行不了的情况。 基于以上情况,vivo Devops对Jenkins的部署架构进行优化搭建,并且配套了一套Jenkins资源调度系统用于管理Jenkins资源。 二、业界实现 目前业界也包含一些Jenkins 高可用的设计方式,但是并不能完全的满足解决上述问题,比如: 2.1 方案一 Gearman + Jenkins 这是OpenStack团队使用的方案。这个方案使用了gearman, gearman是个任务分发框架。 需要在每个Master上安装好gearman的插件,并配置好能连接到gearman server,同时在每个Master必须建立相同的job。 之后运行任务的流程如下: gearman worker运行在各个Jenkins Master中等待gearman server分发任务; gearman client向gearman server发出运行job的请求; gearman server通知各个gearman worker有任务拉,第一个闲着的worker会接受任务,如果所有的worker都忙,则放入gearman的任务队列,得worker空闲时再分配; gearman worker闲下来后会从任务队列里取job来执行,执行完之后,将结果发回给gearman server; gearman server将结果返回给 gearman client。 优点: 这样各个salver资源可以得到充分利用,某个master挂掉另外的master可以继续服务。 弊端: 每个master的slave必须配置一致,否则会造成job调度错误,同时会造成一些资源的浪费。当一个master出现问题,该master的任务不会进行自动重新分配。 2.2 方案二 改造Jenkins的文件存储方式 目前Jenkins的配置文件都是直接在硬盘上以文件形式存储的,你在JENKINS_HOME的个文件夹下能看到各种.xml文件。有些公司在Jenkins上进行二次开发,将Jenkins的数据存储方式改为数据库存储,这样前端可以起多个Jenkins服务,后端连相同的数据库即可。数据库也有比较成熟的高可用方案。 优点: 可以达到Jenkins的高可用也就是某个master挂掉另外的master可以继续服务。 弊端: 需要对Jenkins进行二次开发,使用数据库会降低读取资源效率下降。 2.3方案三 最简单的Jenkins一主一备模式 平时让Jenkins A机器提供服务,并使用SCM Sync configuration plugin保存数据,JenkinsA机器修改配置后触发Jenkins B更新配置,一旦Jenkins A出现问题挂掉后,切换到备机Jenkins B上。 优点: 可以达到Jenkins的高可用,当master宕机后会进行切换到备机上。 弊端: 会有一批Jenkins备机存在资源浪费,切换master时间过长,会导致有段时间Jenkins服务不可用。 三、vivo Jenkins Scheduler系统目标 由于目前业界的一些实现还不能完全的满足我们目前的需求,所以我们进行了vivo jenkins scheduler系统的设计与实现。该系统需要达到如下的目的: 提升整个构建服务可靠性时长。保证jenkins集群的高可用,解决目前master-slave的单点问题,保证整个构建服务的可靠性时长。 降低灾难时服务恢复时长。①提供精准流控方式,在jenkins构建出现请求量过高的时候可以进行流控和持久化操作,减少对目前系统的冲击。②当系统压力减少后,放开流控可以快速的对堆积的请求进行分配执行。 有效分配任务至各个子节点,保证资源的有效利用。 能保证灾难时的及时切换任务至可用节点上,同时能快速的通知管理员进行处理。 能进行数据的可视化分析,能提供一系列帮助改善开发效率的视图,比如构建时长报表、构建量报表等。 四、 vivo Jenkins Scheduler设计 该系统我们从两大部分进行了设计,首先,我们不采用原生的Jenkins部署方案,而是采用全master的方式。第二,设计并开发了一套用于管理Jenkins集群的调度系统。 五、底层 Jenkins 工具部署方案 不采用目前单master的搭建方案,采用多master的搭建方案,master下不进行挂载slave机器,任务直接有master进行处理,master之间的关系、任务分配、离线、插件安装等由调度系统进行管理。这样由于vivo Jenkins Scheduler系统为高可用的,解决了目前Jenkins的单点问题。 六、系统架构图 七、系统说明 7.1 API-Gateway 主要提供系统的外部请求,网关系统,功能包含: 权限校验:校验用户发送集群管理系统的请求的权限。 智能路由:接收外部一切请求,并转发到后端的外服上去。 限流:与监控线程配合(当构建请求达到某个阈值时),进行限流操作。 API日志统一收集:类似于一个aspect切面,记录接口的进入和出去时的相关日志。 数据处理:对请求的参数进行数据的转换处理。 7.2 事件中心 是整个系统通信调用的主要模块,采用的是Spring的Event机制实现,主要核心事件如下: Jenkins注册事件(EVENT_REGIST_JENKINS):Jenkins启动后,通过自定的插件会向系统发送注册请求时,系统接收到后会触发Jenkins管理模块将Jenkins的信息注册至调度系统中。 Jenkins宕机事件(EVENT_DOWN_JENKINS) :监控管理轮询检查Jenkins状态,当发现有Jenkins宕机的情况会触发该事件,Jenkins管理模块处理将Jenkins的信息状态设置为不可用状态,从而是任务不能分配至该台jenkins。 任务从分配事件 (EVENT_JOB_REDO) :当Jenkins宕机后,如果该台jenkins上存在未执行完的任务时候,由job监控模块触发,job管理莫管处理,会对该Jenkins上未执行的job进行重新分配。 任务接受事件 (EVENT_JOB_RECIVE) :当job管理模块接受到创建请求,会触发该事件,由job管理模块放入Redis执行队列。 任务执行事件 (EVENT_JOB_EXECUTE) :job管理模块中的执行线程(10s执行一次,会从Redis队列中弹出任务),弹出任务后触发该事件,由调度中心选取合适的jenkins进行执行。 7.3 调度中心 是整个系统的核心模块,主要的功能是进行执行job时候能选取合适的jenkins进行处理任务,包含两个核心算法: 7.3.1 Jenkins分组算法 每台jenkins都可以使用标签的方式,打上多个标签,比如jenkins可以构建java程序,使用的构建工具可以是maven和gradle,这个时候我们就可以给其打上java、maven、gradle三个标签。 标签的维度主要有以下几个: 标签配置: 判断构建配置是否配置了标签,根据标签选择对应标签的Jenkins,比如配置了(docker等)。 构建语言: 根据构建配置的语言,比如Java、C++、Python、Go等。 构建工具和版本: 比如Maven、gradle、Ant,Cmark、Blade等。 JDK版本:比如JDK7、JDK8等。 Go语言版本:比如1.15.x.、1.16.x等。 GCC版本:如6.x、4.x等。 Python版本:2.x、3.x等。 是否存活:判断Jenkins是否存活,如果宕机直接过滤。 (可选策略)选择执行过该job的Jenkins,减少下载代码的过程:(第一次构建还是会比较慢,可以采用预执行的方式,在配置构建配置的时候,就预先执行一次,这样在用户执行的时候就使用该job执行过得workspace,减少代码下载的时间)。 (可选策略)根据job的构建的平均构建时长,如果构建时长达到某个配置阈值时,优先选择构建器空闲多的Jenkins进行执行,并指出Jenkins的锁定功能。其他的job不允许分配上来。 如果我们给Jenkins打上标签,那么我们就可以使用标签为维度将Jenkins进行分组,并且存入至Redis中缓存,方便后续选取Jenkins用来执行任务: 7.3.2 Jenkins选取算法 当Jenkins分组好了后,我们接受到执行的job的信息就可以使用Jenkins选取算法进行快速的选取合适的Jenkins进行处理job,如下图所示。 其中label子线程、语言子线程……就是我们上面的Jenkins分组的维度,有多少维度,那么这里就会有多少子线程处理。 构建任务进入主线程,然后主线程会按照分组维度分组操作并进行过滤,然后获取到每个分组中合适的Jenkins,再进行取交集(这个时候就获取到可以执行该构建任务的Jenkins了),在判断是否需要经过可选策略,最终得到Jenkins。 7.4 流控管理&队列管理 调度系统中的的任务接受采用的是队列的方式实现,当系统请求量达到阀后,系统将不会进入Redis队列,会将请求持久化至MySQL。后续如果有请求过来,job管理模块会检查数据库MySQL中是否有请求,如果有请求,会将请求放入Redis队列,如果没有请求就会将当前请求放入Redis队列,具体流程如下: 其中基于Redis实现的消息队列的时序图如下: 7.5 回调中心 该模块主要是监控任务的状态,当任务开始执行、中断执行、执行成功、执行失败的时候进行通知业务并存储数据,用于保存构建记录,方便后续数据的统计,用来完成数据的可视化。 八、实施效果 目前该系统已经投入生产环境运行,Jenkins任务已采用调度系统进行调度执行,运行稳定,运行效果。 九、后续展望 随着vivo Jenkins 调度系统的功能慢慢完善,Jenkins的机器也越来越多,目前还大多数运行在虚拟机上,从资源利用率和业务发布效率来看,未来的业务发布形态将会是以容器为主。目前公司也在大力发展k8s的容器生态建设, 所以我们希望将Jenkins工具后期进行容器化、池化,在提高资源利用率和发布效率的同时也可以为用户提供可靠的、简洁的、稳定调度执行。 END 猜你喜欢 100 行 shell 写个 Docker Dubbo 中 Zookeeper 注册中心原理分析 委派模式——从SLF4J说起 本文分享自微信公众号 - vivo互联网技术(vivoVMIC)。如有侵权,请联系 support@oschina.cn 删除。本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

优秀的个人博客,低调大师

数据驱动测试-从方法探研到最佳实践

作者:刘红妍 导读 在自动化测试实践中,测试数据是制造测试场景的必要条件,本文主要讲述了在沟通自动化框架如何分层,数据如何存储,以及基于单元测试pytest下如何执行。并通过实践案例分享,提供数据驱动测试的具体落地方案。 基本概念 数据驱动测试(DDT)是一种方法,其中在数据源的帮助下重复执行相同顺序的测试步骤,以便在验证步骤进行时驱动那些步骤的输入值和/或期望值。在数据驱动测试的情况下,环境设置和控制不是硬编码的。换句话说,数据驱动的测试是在框架中构建要与所有相关数据集一起执行的测试脚本,该脚本利用了可重用的测试逻辑。数据驱动的测试提供了可重复性,将测试逻辑与测试数据分离以及减少测试用例数量等优势。 设计思路 2.1 测试数据 在测试过程中往往需要更加充分地测试场景,而创建数据测试。测试数据包括输入输出,对输出的自动化验证等。创建测试数据,可以通过手动拼装,生产环境拷贝,或通过自动化工具生成。 2.2 数据存储 数据驱动测试中使用的数据源可以是Excel文件,CSV文件,Yaml文件,数据池,ADO对象或ODBC源。 2.3 数据驱动优势 1. 如果应用程序开发还在进行当中,测试者仍然可以进行脚本的编写工作。 2. 减少了冗余和不必要的测试脚本。 3. 用较少的代码生成测试脚本。 4. 所有信息,如输入、输出和预期结果,都以适当的文本记录形式进行存储。 5. 为应用程序的维护提供利了灵活性条件。 6. 如果功能发生了变化,只需要调整特定的函数脚本。 实践分享 基于Laputa框架现有测试脚本,抽离测试数据与测试逻辑,实现数据驱动测试。 Laputa框架简介:Laputa框架基于 Pytest 集成了对API接口自动化, 以及对 Web应用, 移动端应用和 Windows 桌面应用 UI 等自动化的能力。具有可视化的Web界面工具, 便于配置执行规则,关联执行脚本, 触发用例执行,查看执行结果。提供CI集成服务,调用Jenkins API跟踪持续集成结果,开放接口,实现流水线自动化测试。 3.1 环境依赖 3.2.1 参数化配置方式 pytest参数化有两种方式: @pytest.fixture(params=[]) @pytest.mark.parametrize() 两者都会多次执行使用它的测试函数,但@pytest.mark.parametrize()使用方法更丰富一些,laputa更建议使用后者。 3.2.2用 parametrize 实现参数化 parametrize( ) 方法源码: 【python】 def parametrize(self,argnames, argvalues, indirect=False, ids=None, scope=None): 1. 主要参数说明 (1)argsnames :参数名,是个字符串,如中间用逗号分隔则表示为多个参数名。 (2)argsvalues :参数值,参数组成的列表,列表中有几个元素,就会生成几条用例。 2. 使用方法 (1)使用 @pytest.mark.paramtrize() 装饰测试方法; (2)parametrize('data', param) 中的 “data” 是自定义的参数名,param 是引入的参数列表; (3)将自定义的参数名 data 作为参数传给测试用例 test_func; (4)在测试用例内部使用 data 的参数。 创建测试用例,传入三组参数,每组两个元素,判断每组参数里面表达式和值是否相等,代码如下: 【python】 @pytest.mark.parametrize("test_input,expected",[("3+5",8),("2+5",7),("7*5",30)]) def test_eval(test_input,expected): # eval 将字符串str当成有效的表达式来求值,并返回结果 assert eval(test_input) == expected 运行结果: 【python】 test_mark_paramize.py::test_eval[3+5-8]test_mark_paramize.py::test_eval[2+5-7] test_mark_paramize.py::test_eval[7*5-35] ============================== 3 passed in 0.02s =============================== 整个执行过程中,pytest 将参数列表 ("3+5",8),("2+5",7),("7*5",30) 中的三组数据取出来,每组数据生成一条测试用例,并且将每组数据中的两个元素分别赋值到方法中,作为测试方法的参数由测试用例使用。 3.2.3 多次使用 parametrize 同一个测试用例还可以同时添加多个 @pytest.mark.parametrize 装饰器, 多个 parametrize 的所有元素互相组合(类似笛卡儿乘积),生成大量测试用例。 场景:比如登录场景,用户名输入情况有 n 种,密码的输入情况有 m 种,希望验证用户名和密码,就会涉及到 n*m 种组合的测试用例,如果把这些数据一一的列出来,工作量也是非常大的。pytest 提供了一种参数化的方式,将多组测试数据自动组合,生成大量的测试用例。示例代码如下: 【python】 @pytest.mark.parametrize("x",[1,2])@pytest.mark.parametrize("y",[8,10,11]) def test_foo(x,y):print(f"测试数据组合x: {x} , y:{y}") 运行结果: 【python】 test_mark_paramize.py::test_foo[8-1] test_mark_paramize.py::test_foo[8-2] test_mark_paramize.py::test_foo[10-1] test_mark_paramize.py::test_foo[10-2] test_mark_paramize.py::test_foo[11-1] test_mark_paramize.py::test_foo[11-2] 分析如上运行结果,测试方法 test_foo( ) 添加了两个 @pytest.mark.parametrize() 装饰器,两个装饰器分别提供两个参数值的列表,2 * 3 = 6 种结合,pytest 便会生成 6 条测试用例。在测试中通常使用这种方法是所有变量、所有取值的完全组合,可以实现全面的测试。 3.2.4 @pytest.fixture 与 @pytest.mark.parametrize 结合 下面讲讲结合 @pytest.fixture 与 @pytest.mark.parametrize 实现参数化。 如果测试数据需要在 fixture 方法中使用,同时也需要在测试用例中使用,可以在使用 parametrize 的时候添加一个参数 indirect=True,pytest 可以实现将参数传入到 fixture 方法中,也可以在当前的测试用例中使用。 parametrize 源码: 【python】 def parametrize(self,argnames, argvalues, indirect=False, ids=None, scope=None): indirect 参数设置为 True,pytest 会把 argnames 当作函数去执行,将 argvalues 作为参数传入到 argnames 这个函数里。创建“test_param.py”文件,代码如下: 【python】 # 方法名作为参数 test_user_data = ['Tome', 'Jerry'] @pytest.fixture(scope="module") def login_r(request): # 通过request.param获取参数 user = request.param print(f"\n 登录用户:{user}")return user @pytest.mark.parametrize("login_r", test_user_data,indirect=True) def test_login(login_r): a = login_r print(f"测试用例中login的返回值; {a}") assert a != " 运行结果: 【plain】 登录用户:Tome PASSED [50%]测试用例中login的返回值; Tome 登录用户:Jerry PASSED [100%]测试用例中login的返回值; Jerry 上面的结果可以看出,当 indirect=True 时,会将 login_r 作为参数,test_user_data 被当作参数传入到 login_r 方法中,生成多条测试用例。通过 return 将结果返回,当调用 login_r 可以获取到 login_r 这个方法返回数据。 图1 @pytest.fixture 与 @pytest.mark.parametrize 结合读取数据图例 3.2.5 conftest作用域 其作用范围是当前目录包括子目录里的测试模块。 (1)如果在测试框架的根目录创建conftest.py文件,文件中的Fixture的作用范围是所有测试模块。 (2)如果在某个单独的测试文件夹里创建conftest.py文件,文件中Fixture的作用范围,就仅局限于该测试文件夹里的测试模块。 (3)该测试文件夹外的测试模块,或者该测试文件夹外的测试文件夹,是无法调用到该conftest.py文件中的Fixture。 (4)如果测试框架的根目录和子包中都有conftest.py文件,并且这两个conftest.py文件中都有一个同名的Fixture,实际生效的是测试框架中子包目录下的conftest.py文件中配置的Fixture。 3.3 代码Demo 测试数据存储yaml文件: 【YAML】 测试流程:[ {"name":"B2B普货运输三方司机流程","senior":{"createTransJobResource":"B2B","createType":"三方","platformType":2}}, {"name":"B2B普货运输三方司机逆向流程","senior":{"isback":"True","createTransJobResource":"B2B","createType":"三方","platformType":2}}, ] 测试数据准备,定义统一读取测试数据方法: 【python】 def dataBuilder(key):dires = path.join(dires, "test_data.yaml") parameters = laputa_util.read_yaml(dires)[key] name = [] senior = [] for item in parameters: name.append(item['name'] if 'name' in item else '') senior.append(item['senior'] if 'senior' in item else '') return name, senior 测试用例标识,通过@pytest.mark.parametrize方法驱动用例: 【python】 class TestRegression: case, param = dataBuilder('测试流程') @pytest.mark.parametrize("param", param, ids=case) def test_regression_case(self, param): # 调度 res = create_trans_bill(params) trans_job_code = res['data']['jobcode'] carrier_type = params['createType'] if params['createType'] in ('自营', '三方') else '个体' # 执行 work_info = select_trans_work_info_new(trans_job_code) trans_work_code = work_info['trans_work_code'] if 'isback' in params and params['isback']: execute_param.update(isBack=params['isback']) execute_bill_core(**execute_param) # 结算 if carrier_type != '自营': trans_fee_code = CreateTransFeeBillBase.checkTF(trans_job_code) receive_trans_bill_core(**bill_param) 总结 日常测试过程中,无论是通过手动执行或者脚本执行,都需要利用数据驱动设计思路,这有助于提高测试场景覆盖率,测试用例的健壮性和复用性,及需求测试效率。通过数据驱动测试不仅可以得到更好的投资回报率,还可以达到质效合一的测试流程。

优秀的个人博客,低调大师

淘系自研前端研发工具 AppWorks 正式发布

经过了一年的迭代, 近 2 个月集中开发,AppWorks正式发布。 AppWorks地址:https://appworks.site/ AppWorks 是社区受到开发者广泛关注的 VS Code 套件,在 VS Code 插件市场有 2w+ 的下载量,是 VS Code 插件市场受开发者喜爱的百佳套件之一,多次登陆 VS Code 插件市场周/月趋势榜。在淘宝内部,AppWorks 日均创建项目 50+ 次,日均区块被使用 50+ 次,DAU 400+。 AppWorks 正式版本定位前端研发工具集,目标是让前端应用的开发更快更好更轻松 什么是工具集?工具集是指 AppWorks 包含了一系列面向前端研发各场景的工具(桌面客户端、编辑器插件、命令行工具等)。 为什么是更快更好更轻松?快、好和轻松是指前端研发过程中需要解决的三个核心问题:研发效率(要更快)、代码质量(要更好)、研发门槛(要更轻松)。 这篇文章将主要介绍 AppWorks 有哪些能力,以及如何使用这些能力解决这些问题的。 让开发门槛再低一点 好的工具应该是人人都用得起的。AppWorks 首要解决的问题是让人人都可以快速地开始前端研发。面对这个问题,AppWorks 提供的解法是 GUI 工具 + 海量可复用物料。 ▐开发工具箱 要开始前端应用程序的开发,首先需要安装必要开发工具和配置相应的开发环境: 必要的开发工具包括:Visual Studio Code、Google Chrome、Charles等等; 配置的开发环境包括:Node.js、npm、git等等。 VisualStudioCode地址:https://code.visualstudio.com/ Google Chrome地址:https://www.google.cn/chrome/ Charles地址:https://www.charlesproxy.com/ Node.js地址:https://nodejs.org/en/ npm地址:https://www.npmjs.com/ git地址:https://git-scm.com/ 为此 AppWorks 提供前端开发工具箱 ——AppWorks Toolkit来帮助开发者简单快速搭建前端开发环境。 AppWorks Toolkit地址:https://github.com/appwork4s-lab/toolkit Toolkit 是一个桌面客户端,开发者可以快速安装和使用。其核心能力有: 一键安装前端开发工具,这些工具包括但不限于:桌面客户端、编辑器插件、浏览器插件、命令行工具等等; 可视化管理前端开发工具,覆盖工具查找、安装、升级、卸载完整的软件生命周期管理; 可视化配置前端开发环境,这些配置包括但不限于:Node 配置、npm 配置、Git 配置等等。 更详细的说明可以参见:《前端环境》 阅读地址:https://appworks.site/pack/basic/toolkit.html ▐海量可复用物料 前端开发的第二步需要有海量可复用的物料。物料只有海量和可复用,才能正在地服务于前端应用的开发,其要求是: 海量:面向不同的终端有对应的跨端跨框架的物料; 可复用:需有较高的领域抽象度和可维护的代码质量。 为此 AppWorks 提供物料解决方案 ——AppWorks Material来满足这些要求: AppWorks 物料方案的特点有: 丰富且高质量的物料:从业务中抽象并经过多轮 Review,支持了 Fusion Design、Ant Design、Rax 等不同 UI 组件的物料; 可定制物料的能力:提供脚手架工具供不同团队快速定制业务领域的模板、区块和组件形成物料库; 低成本的文档站点:打通 Fusion 物料中心的托管,可以快速形成物料的站点和文档。 让好的开发体验促进效率的提升 好的工具应该能够提供好的开发体验并促进效率的提升。为此 AppWorks 提供了基于 VS Code 的前端研发套件 ——AppWorks Pack从以下几个方面来提高源码开发领域的体验和效率。 AppWorks Pack地址:https://marketplace.visualstudio.com/items?itemName=iceworks-team.iceworks ▐极简的开发流程 Pack 将创建、调试和发布项目等操作通过插件的方式集成到了 VS Code 中,在编辑器内即可完成常见的工程操作以及与线上平台的对接。这些能力的集成使得开发者不需要频繁地在多个客户端、平台间进行切换和学习: ▐友好的可视化开发 Pack 提供了基于物料的可视化开发方式,基于AppWorks Material提供的海量物料,通过区块组装生成页面,一键添加物料到代码,物料的文档、示例都可以在编辑器中直接触达: 更详细的说明可以参见:《使用物料》 阅读地址:https://appworks.site/pack/basic/materials.html ▐强大的编码辅助 Pack 提供的编码辅助能力包括:代码提示(自动补全、信息提示和定义跳转)、代码重构和代码片段等功能,这些功能是覆盖多种编程语言(JavaScript、CSS)和多种 DSL(React、Rax)和多套研发框架(rax-app、ice.js)的。 以 Pack 提供代码重构功能为例,可以快速删除组件文件及组件文件所有的引用,同时删除掉由于组件属性所带来的不需要的变量: 更详细的说明可以参见:《代码补全》、《代码重构》 阅读地址: 《代码补全》:https://appworks.site/pack/basic/intelli-code.html 《代码重构》:https://appworks.site/pack/basic/refactor-code.html 让好的代码获得持续的关注 好的代码质量是软件工程的立身之本,好的开发工具应该能够为软件工程的代码质量提供保障。 为此 AppWorks 提供了代码质量解决方案 ——AppWorks Doctor来解决该问题。Doctor 提供了代码规范和项目质量评估模型,并结合编辑器来进行自动修复规范问题和产出项目质量评估报告;线上则提供数据大盘来全面了解团队和项目的质量情况,帮助开发者和管理者对代码质量保持持续的关注。 ▐代码规范 Doctor 通过@appworks/spec包来声明和约束代码规范。该规范遵循阿里巴巴前端编码规范,并结合了我们在ICE和Rax项目的最佳实践,包含 ESLint、stylelint、commitlint 及 Prettier 的相关规则,开发者可以很方便地与自己的前端项目进行结合。 地址: @appworks/spec:https://www.npmjs.com/package/@appworks/spec ICE:https://ice.work/ Rax:https://rax.js.org/ ▐质量分析 Doctor 建立了项目质量评估模型,该模型包含以下几个维度的分析: 代码规范:通过 @appworks/spec扫描代码,并提供一键修复功能(Doctor 提供了默认的配置,但用户项目的 @appworks/spec 配置优先级将更高)。 代码可维护度:通过typhonjs-escomplex扫描代码。复杂度评分低说明代码的判断逻辑复杂,可能质量低且难于阅读、测试和维护。 代码重复度:通过jscpd扫描代码。重复的代码一旦出错,意味着加倍的工作量和持续的不可控。将提示进行代码抽象和重构来减少冗余代码。 地址: typhonjs-escomplex:https://www.npmjs.com/package/typhonjs-escomplex jscpd:https://www.npmjs.com/package/jscpd 开发者可以在 VS Code 中对自己的本地项目进行质量检测,并自动修复规范问题,查看维护度和重复度方面的分析及优化建议: 亦或者针对依赖的基础库和框架进行自动化的升级,Doctor 也提供了人为监督和偶尔干预的方式: ▐线上治理 代码规范和质量分析让开发者可以在本地主动地去优化项目的质量。但对于团队来说,依然需要有被动的方式来促进项目的质量治理。例如了解重点项目的质量趋势情况,团队成员的质量情况,推进落地最佳实践或某些依赖包的升级等等。 在阿里内部,Doctor 通过对接 DEF 工程平台,在项目的发布部署环节收集项目的质量信息,并给开发者发送此次迭代的质量报告,由此来提升团队成员的质量意识。同时发布环节的质量检测是可控的,当遇到一些特殊情况时,例如我们发现了某个有重大缺陷或安全问题的代码或依赖包,可以中断此次发布流程: 通过对项目发布时质量情况的采集,Doctor 能够知道团队内项目和成员的质量概况和趋势,在AppWorks Data Platform上进行数据的展示和分析: 地址: AppWorks Data Platform:https://appworks.alibaba-inc.com/ 这里面目前开发经常使用的场景是在线上网站展示项目的质量信息,开发者可以通过跳转到 WebIDE 唤起 Doctor 插件完成一键修复和优化代码: 让提升代码编率可度量 广义的研发效率是指软件从需求到上线的完整过程中的投入和产出比。编程效率是指单位时间内有效的代码产出,编程效率是研发效率的重要组成部分。 AppWorks 目标通过定义编程效率的评估标准,产出团队的编程效率报告,分析影响编程效率的因素,制定提升编程效率的方案,对方案进行实施,观测效率数据变化,调整提效方案,最终达到提升个人和团队编程效率的目的。 现阶段,AppWorks 主要完成了编程数据的采集及统计。 ▐数据采集 AppWorks 通过 Time Master 插件来将自动追踪开发者在编辑器中的编码行为,Time Master 采集的数据包括开发者的编辑器使用时长及其在编辑器上针对代码文件的所有操作,例如打开文件、关闭文件、在代码文件上进行键入等; 最终可以做到统计开发者在每个文件、每个项目的详细编辑行为,例如: 停留时长 编辑时长 添加、删除的代码行数 添加、删除的字符数 键盘输入数 等等 在阿里内网环境,Time Master 将会把这些数据上报到 AppWorks Data Platform。 ▐数据分析 基于上报的数据,AppWorks Data Platform 可以提供个人、项目和团队编程数据的统计和分析: 项目大盘:提供具体项目的成员开发投入情况的数据统计及分析; 个人大盘:提供个人质效数据统计及分析,并与团队的整体情况进行对比; 团队大盘:提供团队整体的项目质效数据统计及分析,团队成员的质效概况。 未来展望 ▐编码辅助增强 从过往一年的用户使用数据来看,编码辅助功能依然是开发者使用最频繁的功能,对该功能准确率的提升会促进曝光率和转换率的提升: 转换率:使用量/曝光量 曝光率:曝光量/活跃用户数 从日常的用户访谈来看,开发者对基础库和框架的代码提示和代码重构有迫切的期待,诸如快速提取代码、快速变量命名、Inline Style to CSS 等操作,能为开发者提供愉悦的编码体验。未来 AppWorks 将持续增强编码辅助能力,并结合 Time Master 对相关功能的实际编码效率提升进行量化。 ▐项目质量治理 AppWorks 在上一个年度完成了 Data Platform 的雏形,打通了质量数据的上报、存储和统计链路。 但有数据只是提供了参考价值,基于数据做出行动,持续完善数据模型,使得指标数据提升,才能完成体现数据中心的价值。 未来 AppWorks 将通过线上网站和编辑器端信息的触达,让开发者和管理者了解基础库和框架的最新动态,配套升级工具,推动团队基础设施的升级。例如通过线上线下的联动,推进 React 15 升级到 17,Rax 核心库从 0.6 升级到 1.0 等等。 ▐工具箱能力完善 AppWorks Toolkit 的第一个版本中已完成快速安装必备工具和管理 Node 版本功能。未来将持续完善对前端工具和开发环境的管理和配置能力,成为前端开发的第一入口,帮助初学者快速开始前端开发,引导开发者用好工具,排查和修复开发环境问题。例如: 全局 npm 的管理 Git/SSH 配置 浏览器/编辑器插件管理 ▐编程数据价值挖掘 AppWorks 在上一个年度完成了编程数据的上报、存储和统计链路。未来 AppWorks 将主要通过 API 或离线数据分享的方式,让业务平台和工程平台利用编程数据进行研发效能的度量或分析,使得数据价值更大化。 写在文末 AppWorks 将持续重视用户体验,做开发者喜欢的、好用的工具。任何建议或意见,可以提交 issue 给我们:https://github.com/appworks-lab/site/issues 相关资料 AppWorks 官网:https://appworks.site AppWorks Toolkit: https://github.com/appworks-lab/toolkit AppWorks Pack: https://marketplace.visualstudio.com/items?itemName=iceworks-team.iceworks AppWorks Material: https://appworks.site/materialCenter/fusion

资源下载

更多资源
Mario

Mario

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

腾讯云软件源

腾讯云软件源

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

Nacos

Nacos

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

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册