您的位置:时时app平台注册网站 > 编程知识 > 全新的 flow.ci Dashboard UI 上线

全新的 flow.ci Dashboard UI 上线

2019-09-10 19:31

更简单快捷地创建项目

新版的创建项目默认选择最近使用的代码仓库和组织,创建项目的流程从上一版的「选择项目-选择代码仓库-选择组织-选择项目」的 4 个步骤简化成「选择代码仓库-选择组织」两步,同时左边显示个人账号和组织,右边显示已经授权的项目,也更加清晰方便。

图片 1flow.ci

好久不见 :)

Pull Requests

在 Pull Requests 中可以列表查看并管理 Pull Request。代码的更改和讨论都可以在这里进行。旁边显示的数字表示尚未 Close 的 Pull Request的数量。

全新的构建列表页面

创建项目后开始进行构建,整个构建列表页面进行了重构,分别列出了“全部构建”“分支”“PullRequest”三个页面,以供构建者参考。首先,在全部构建里可以筛选分支,选择你想要关注的分支。

图片 2

整个构建页面以“构建任务”为核心,当构建任务完成时,能一目了然地看到构建 id 和分支名称,构建状态(失败/成功/已停止)、相关的构建发起者和构建日志,同时也可以在列表任务右侧看到构建时间、构建时长、组织名称。这里值得一提的是,我们新添加了构建项目的仓库链接,这样很容易能看到上次提交的代码和这次更新的代码的对比,方便定位构建失败的代码。

图片 3flow.ci

还有一个微小的细节,点击“只查看我的提交”的按钮,你可以更专注于自己的构建任务。

进入分支页面,分为关注分支和活跃分支,可预览和汇总每个分支最近 5 次构建结果。

关注分支中默认关注 master 分支;活跃分支默认了展示最近构建次数较多的分支,可选择标记置顶相对重要的分支。

图片 4

我们发现开发者在构建过程中会比较关注 Pull Request 的构建结果,单独列出来会更方便查看。在每条 Pull Request 构建结果的右侧,也添加了构建项目的仓库链接,与 Pull Request 构建的分支一一对应定位,方便查看代码构建的改动。

图片 5flow.ci

细心的人肯定发现了右上角新增加的监控图标,点开会呈现跨项目的构建任务和最近 20 次的构建;项目监控可查看组织下各个项目的构建状态,同时展现最近一次的项目构建状态和结果,点击可直接跳转到具体的 job 日志页面。

图片 6

这是新版的 Dashboard 页面的改版,希望你会喜欢,在使用过程中有任何反馈通过网站[在线消息]或者来flow.ci 社区找到我们。

Enjoy :)

微服务的持续集成,四步“构建”一个代码世界

这篇文章讲述了持续集成之构建、部署、测试和发布的种种,如果你对这些有所疑惑,这篇文章可能会有你想要的答案。(via : EAii企业架构创新研究院-公众号)

Broadcast

主要用于接收 GitHub 公司发来的通知或使用技巧的小贴士。

全新的 flow.ci Dashboard 页面上线了,更快捷地创建项目,构建列表页面新增分支,Pull Request 界面;侧边栏新增构建任务监控和项目监控,整个 Dashboard 界面焕然一新,一起来看看新版的变化吧~

这期CI Weekly收录了一些最新的微服务/持续集成分享、自动化测试、工程师文化相关的技术分享,希望对你有用~

集中型

以 Subversion 为代表的集中型,所示将仓库集中存放在服务器之中,所以只存在一个仓库。这就是为什么这种版本管理系统会被称作集中型。

集中型将所有数据集中存放在服务器当中,有便于管理的优点。但是一旦开发者所处的环境不能连接服务器,就无法获取最新的源代码,开发也就几乎无法进行。服务器宕机时也是同样的道理,而且万一服务器故障导致数据消失,恐怕开发者就再也见不到最新的源代码了。

除此之外,flow.ci 也做了些许「功能优化」与「问题修复」,性能和体验在持续优化中。比如:

Wiki

Wiki 是一种比 HTML 语法更简单的页面描述功能。常用于记录开发者之间应该共享的信息或软件文档。数字表示当前 Wiki 的页面数量。所有
有权限的人都可以对文章进行修改,所以比较适合多人共同编写文章的情况。创建、编辑文档时不必另外启动软件,用起来十分方便,非常适合用来针对更新频率较高的软件进行文档等信息方面的汇总。一般情况下,Wiki 中记载着软件相关的 FAQ、文档、代码示例及解说等信息。

  • 支持GFM。
  • Wiki 功能本身的数据也在 Git 中进行管理。
    • 用户能够通过 clone操作获取 Wiki 仓库,然后在本地创建、编辑页面,进行提交再 push,便可以完成对 Wiki 的创建及编辑工作。
  • 在 Pages 标签页中可以列表查看 Wiki 页面。
  • 在 History 标签页中可以查看 Wiki 的修改历史记录。
  • 所有 Wiki 页面都可以显示侧边栏。
    • 做法很简单,只要创建名为“_sidebar”的页面即可。_sidebar 页不会显示在 Pages 的页面一览中。在编辑各页面时页面下部会附加 Sidebar 段,用户可以在这里编辑侧边栏的内容。

图片 7

GitHub Enterprise

GitHub Enterprise 专为那些无法将源代码放到公司之外的企业设计。这项服务可以以虚拟机的形式提供 GitHub。

Web 持续集成工作实践

作者将一些自动化工具和方法等持续集成引入到工作中的一些经验和教训。 (via: @运维帮 王集鹄) ​​​​

代码管理方式——集中与分散

自动化测试与持续集成方案合集

作者的这一系列分享包括接口测试、Android crash 收集、Android/iOS Daily Build、Jmeter 测试接口及性能、Android 兼容性测试、代码检查等等,非常详细。(via:Testerhome @snake )

github上的交流:

GitHub 中可使用的描述方法并不止“@ 用户名”一种。

输入“@ 组织名”可以让属于该 Organization(组织)的所有成员收到通知 7。输入“@ 团队名”可以让该团队的所有成员收到通知。这就是同时向多人发送通知的方法。

输入“# 编号”,会连接到该仓库所对应的 Issue 编号。输入“用户名 / 仓库名 # 编号”则可以连接到指定仓库所对应的 Issue 编号。只要按照这类特定格式书写便会自动创建链接。

只要将感兴趣的仓库添加至 Watch 中,就可以在 News Feed 查 看该仓库的相关信息。

为什么要重构到微服务

这篇文章讲了使用微服务架构来重构现有系统,描述了在这过程中整团队做的选择、取得的成果、走过的弯路,以及经验教训。(via : 微信公众号“凤凰牌老熊”)


以上是 CI Weekly #15 的所有技术分享,
如有问题,请联系我们~

Happy building!
flow.ci

CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享,包括国内外持续集成、持续交付,持续部署、自动化测试、 DevOps 等实践教程、工具与资源,以及一些工程师文化相关的程序员 Tips 。同步于 flow.ci Blog、微信公众号、官方微博,知乎专栏,简书,欢迎关注或投稿:)

Settings

关于仓库的设置。

2017年云趋势——从DevOps到NoOps

本文介绍了2017年DevOps的最新趋势,提出了NoOps的概念,并且提出了采用智能化技术来促进DevOps向NoOps转型的思想。(via
:dockerone.io - 付辉 翻译)

Graphs

在 Graphs 页中,可以通过 4 种图表查看该仓库的相关统计信息。

更多详情见 flow_ci changelog. 如果你在使用过程中遇到问题,可以通过「在线消息」或去 flow.ci 社区 反馈给我们 :)

快捷键

在 GitHub 中,很多页面都可以使用键盘快捷键。在各个页面按下 shift + / 都可以打开键盘快捷键一览表,查看当前页面的快捷键。

基于 flow.ci 和 Coding 的 Hexo 自动构建

“ flow.ci 相比较而言配置过程更简单,构建和访问速度更快捷。”这篇文章作者写了使用 flow.ci coding 完成博客的自动构建。(via : @Ethan-城子 )

GitHub Pages

GitHub 有一个名为 GitHub Pages 的仓库,用户可以利用该仓库中的资料创建 Web 页,用来发布仓库中软件的相关信息。如果已经创建过GitHub Pages,则会显示相应 URL。点击 Automatic Page Generator 即可以自动创建 GitHub Pages。

  • 支持 React Native;
  • 优化 iOS build 脚本,上传证书后才可进行 build;
  • 邮件模板优化;
  • iOS 项目的 Scheme 配置支持特殊符号;
  • 支持 Android Support Repository.

Blog

这是到 GitHub 公司官方博客的超链接,GitHub 公司会在上面发布通知。新功能的通知、新入职员工的介绍、drinkup 聚会的信息等都会在上面定期发布。

GitHub 上的测试覆盖率

本篇文章主要介绍一下测试覆盖率的概念以及如何将测试覆盖率的 badge 添加到 README.md 中。(via : Twitter@xcatliu)

News Feed

显示当前已 Follow 的用户和已 Watch 的项目的活动信息,用户可以在这里查看最新动向。将右上角 RSS 标志的 URL 添加到 RSS 阅读器中,还可以通过 RSS 查看。

最近工程师们卯足了劲,全新的 flow.ci dashboard 页面 已经与所有用户见面了。更快捷地创建项目,构建列表页面新增分支,Pull Request 界面;侧边栏新增构建任务监控和项目监控,整个 Dashboard 界面焕然一新,快去 flow.ci 体验一下吧。

Code Frequency

Code Frequency 中显示了该仓库中代码行数的增加量和删除量。一款优秀的软件并不会一味地增加代码,在经过重构之后,代码量往往会降低。

提交与Issue的交互

在 Issue 一览表中我们可以看到,每一个 Issue 标题的下面都分配了诸如“#24”的编号。只要在提交信息的描述中加入“#24”,就能在 Issue 中显示该提交的相关信息,使关联的提交一目了然。这里只需轻轻点击一下便可以显示相应提交的具体内容,在代码审查时省去了从大量提交日志中搜索相应提交的麻烦,非常方便。

如果一个处于 Open 状态的 Issue 已经处理完毕,只要在该提交中以下列任意一种格式描述提交信息,对应的 Issue 就会被 Close。

  • fix #24
  • fixes #24
  • fixed #24
  • close #24
  • closes #24
  • closed #24
  • resolve #24
  • resolves #24
  • resolved #24

releases

显示仓库的标签(Tag)列表。同时可以将标签加入时的文件以归档形式(ZIP、tar.gz)下载到本地。软件在版本升级时一般都会打标签,如果需要特定版本的文件,可以从这里寻找。

Files Changed

Files Changed 标签页中可以查看当前 Pull Request 更改的文件内容以及前后差别。标签上的数字表示新建及被更改的文件数。默认情况下系统会将空格的不同也高亮显示,所以在空格有改动的情况下会难以阅读。这时只要在 URL 的末尾添加“?w=1”就可以不显示空格的差别。将鼠标指针放到被更改行行号的左侧,我们会看到一个加号。点击这个加号可以在代码中插入评论。这样,评论是针对哪行代码的就一目了然了。

分散型

GitHub 将仓库 Fork 给了每一个用户。Fork 就是将 GitHub 的某个特定仓库复制到自己的账户下。Fork 出的仓库与原仓库是两个不同的仓库,开发者可以随意编辑。

分散型拥有多个仓库,相对而言稍显复杂。不过,由于本地的开发环境中就有仓库,所以开发者不必连接远程仓库就可以进行开发。

CONTRIBUTING.md

在描述 Issue 时,常常会看到贡献规范的链接。

在该仓库的根目录下添加 CONTRIBUTING.md 文件后该链接就
会显示出来。规范的内容一般包括报告时Issue的描述方法、Pull Request 时的规则或要求、许可证的相关信息等。为了在开源项目开发中能与其他人和谐相处,请务必在贡献之前仔细阅读这些规范。

Clone in Desktop

启动 GitHub 专用的客户端应用程序并进行 clone。

Your Repositories

按更新时间顺序显示用户的仓库。标有钥匙图案的是非公开仓库,标有类似字母 Y 图案的是用户 Fork 过的仓库。

Notifications

每当创建 Issue、收到评论、创建 Pull Request 等情况发生时,我们就会在 Notifications 中收到通知。

Pull Requests

显示用户已进行过的 Pull Request。通过这里,开发者可以很方便地追踪 Pull Request 的后续情况。

Pull Request 是用户修改代码后向对方仓库发送采纳请求的功能。在列表中点击特定的 Pull Request 就会进入详细页面。页面上方显示着这次是从谁的哪个分支向谁的哪个分支发送了 Pull Request。

Issues

在这里可以查看用户拥有权限的仓库或分配给自己的 Issue。当用户同时进行多个项目时,可以在这里一并查看 Issue。

GitHub Pages

GitHub Pages 主要用于在 GitHub 上托管静态 HTML,以便发布项目的 Web 页。可以绑定独立域名。常被使用为静态博客。

Public contributions

一格表示一天,记录当日用户对拥有读取权限的仓库的大致贡献度。贡献度的衡量标准包括发送 Pull Request 的次数、写 Issue 的次数、进行提交的次数等。颜色越深代表贡献度越高。

Gist

Gist 是一款简单的 Web 应用程序,常被开发者们用来共享示例代码和错误信息。它使用JavaScript 编写的 Ace 编辑器,只需打开浏览器便可编写简单代码。另外,Gist 中的文档都在版本管理系统的管理之下,用户可以放心编辑。而且由于其版本历史记录保管在 Git 仓库中,所以还可以通过clone 操作将 Gist 获取至本地。共享 Gist 的人之间能够互相添加评论,所有交流都会被记录下来。Gist 支持多种语言的语法高亮,可以大幅增强代码可读性。可以说,这一工具就是专为程序员设计的。

Tasklist语法

使用 GFM 的一项独有功能,那就是 Tasklist 语法。

# 本月要做的任务
- [ ] 完成图片
- [x] 完成部署工具的设置
- [ ] 实现抽签功能

Webhooks & Services

在这个页面中,用户可以添加 Hook 让 GitHub 仓库与其他服务集成。通过 Add webhook 可以添加用户自己的 webhook。通过 Configureservices 则可以从 GitHub 事先列出的可以集成的服务中进行选择。能与GitHub 集成的服务非常多,其中还包括邮件及 IRC 等社交服务。

Commits

在 Commits 标签页中,按时间顺序列表显示了与当前 Pull Request相关的提交。标签上的数字为提交的次数。每个提交右侧的哈希值可以连接到该提交的代码。

在评论中输入“:”(冒号)便会启动表情自动补全功能。只要输入几个与该表情相关的字母,系统就会为您筛选自动补全的对象。选择想要的表情,其相应代码(前后都有冒号的字符串)便会插入到文本框中。

(请登录 http://www.emoji

  • cheat - sheet.com/ 查找可使用的表情)

URL使用技巧

  • https://github.com/rails/rails/compare/4-0-stable...3-2-stable

这样,就可以查看两个分支间的差别。

  • https://github.com/rails/rails/compare/master@{7.day.ago}...master

查看 master 分支在最近 7 天内的差别,支持day,week,month,year。如果差别过大则不会列出所有提交,只显示最近的一部分。

  • https://github.com/rails/rails/compare/master@{2013-01-01}...master

查看 master 分支 2013 年 1 月 1 日与现在的区别。但是如果指定日期与现在的差别过大,或者指定日期过于久远,则无法显示。

Conversation

可以查看与当前 Pull Request 相关的所有评论以及提交的历史记录。提交日志的右侧有该提交的哈希值,点击链接即可确认相应提交的详细信息。

可以使用R键快速引用选中的评论。

Deploy Keys

在这个页面中,用户可以添加用于部署的公开密钥,允许以只读方式访问仓库。设置公开密钥后,用户可以使用私有密钥通过 ssh 协议 clone 仓库。要注意的是,这里添加的公开密钥·私有密钥对无法再添加到其他仓库。使用 Deploy Keys 功能时,需要给每个仓库赋予不同的密钥对。

链接妙用

假设 Pull…Request 的 URL 如下所示。

https://github.com/用户名/仓库名/pull/28

如果想获取 diff 格式的文件,只要像下面这样在 URL 末尾
添加 .diff 即可。

https://github.com/用户名/仓库名/pull/28.diff

同 理, 想 要 patch 格 式 的 文 件, 只 需 要 在 URL 末 尾 添加 .patch 即可。
   
https://github.com/用户名/仓库名/pull/28.patch

其他功能

GitHub相关

Graphs

以图表形式显示该仓库的各项指标。让用户轻松了解该仓库的活动倾向。

Issue

用于 BUG 报告、功能添加、方向性讨论等,将这些以 Issue 形式进行管理。Pull Request 时也会创建 Issue。旁边显示的数字是当前处于Open 状态的 Issue 数。

在软件开发过程中,开发者们为了跟踪 BUG 及进行软件相关讨论,进而方便管理,创建了 Issue。管理 Issue 的系统称为 BTS(Bug Tracking System,BUG 跟踪系统)。当今具有代表性的 BTS 有 Redmine,Trac,Bugzilla等。GitHub 也为自身加入了 BTS 的功能。

  • 支持markdown语法
  • 支持指定语法时代码高亮
  • 支持拖拽添加图片
  • 支持添加标签整理 Issue
  • 支持添加里程碑来管理 Issue(类似于进度条的一个东西)

Compare & review

可以查看当前显示的分支与其他分支的差别,以便进行审查。点击这个按钮,会出现一个页面让用户选择比较对象。

Punchcard

从 Punchcard 的图中我们可以直观地掌握一周内每天何时收到的提交最多。黑色圆越大,表示提交越频繁。仓库的关键人物往往会出现在提交频率高的时间段,因此用户发送的 Pull Request 最有可能在这段时间内被处理。大致了解时间规律,将有助于各位把握好发送 Pull Request 以及等待回复的时间点。另外,该软件的开发是集中在早上还是晚上,从这张图中也可一目了然。

Network

以图表形式显示包括克隆仓库在内的所有分支的提交。从图上可以直观地看出每个人做了多少工作。将鼠标指针停留在表中提交或合并的点上,可以查看相应的参考内容。

GitHub API

GitHub 面向开发者公开了 API。

行链接

文件内容的左侧会显示该文件的行号。假如我们点击第 10 行的行号,这一行就会被高亮标记为黄色,同时 URL 末尾会自动添加“#L10”。使用这个 URL,程序员们在交流时,就可以将讨论明确指向某一行。另外,如果将“#L10”改成“#L10-15”,则会标记该文件的第10~15 行。

在仓库页面试着按下键盘的 t 键,然后输入要找的目录或文件的部分名称。筛选器会在仓库的目录和文件中进行筛选,搜索出您要找的文件。

Issue与Pull Request

在 GitHub 上,如果给 Issue 添加源代码,它就会变成我们马上要讲到的 Pull Request。Issue 与 Pull Request 的编号相互通用,通过 GitHub的 API 可以将特定的 Issue 转换为 Pull Request,能够完成这一操作的是 hub 命令。

Collaborators

用户主要在这里设置仓库的访问权限。如果仓库隶属于个人账户,那么可以添加 GitHub 的用户名,赋予该用户直接读写仓库的权限。不过,如果仓库隶属于 Organization 账户,则需要像所示的那样先创建 Team,然后赋予该 Team 读写仓库的权限。像这样使用 Organization 账户可以高效地设置仓库权限,在公司等多人共同进行开发的组织中,建议使用 Organization 账户。

Public Activity

从这里可以了解到该用户平常都在 GitHub 上做些什么。比如查看一下崇拜已久的程序员的公开活动,就可以知道他现在关注些什么,或者正在热心于开发些什么。

Explore

从各个角度介绍 GitHub 上的热门软件。

  • GitHub 公司特别介绍的软件(附开发者制作的视频)
  • 按语言筛选本日 / 周 / 月的热门仓库 / 开发者

Pulse

显示该仓库最近的活动信息。该仓库中的软件是无人问津,还是在火热地开发之中,从这里可以一目了然。

Gist

Gist 功能主要用于管理及发布一些没必要保存在仓库中的代码,比如小的代码片段等。系统会自动管理更新历史,并且提供了 Fork 功能。在 Gist 上添加的代码示例可以嵌入博客中。当然,如果选择了语言,还会自动添加语法高亮。

本文由时时app平台注册网站发布于编程知识,转载请注明出处:全新的 flow.ci Dashboard UI 上线

关键词: