mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-01 21:50:13 +08:00
commit
a18e8b70c2
466
published/20161025 GitLab Workflow An Overview.md
Normal file
466
published/20161025 GitLab Workflow An Overview.md
Normal file
@ -0,0 +1,466 @@
|
||||
GitLab 工作流概览
|
||||
======
|
||||
|
||||
GitLab 是一个基于 git 的仓库管理程序,也是一个方便软件开发的强大完整应用。
|
||||
|
||||
GitLab 拥有一个“用户新人友好”的界面,通过图形界面和命令行界面,使你的工作更加具有效率。GitLab 不仅仅对开发者是一个有用的工具,它甚至可以被集成到你的整个团队中,使得每一个人获得一个独自唯一的平台。
|
||||
|
||||
GitLab 工作流逻辑符合使用者思维,使得整个平台变得更加易用。相信我,使用一次,你就离不开它了!
|
||||
|
||||
### GitLab 工作流
|
||||
|
||||
**GitLab 工作流** 是在软件开发过程中,在使用 GitLab 作为代码托管平台时,可以采取的动作的一个逻辑序列。
|
||||
|
||||
GitLab 工作流遵循了 [GitLab Flow][97] 策略,这是由一系列由**基于 Git** 的方法和策略组成的,这些方法为版本的管理,例如**分支策略**、**Git最佳实践**等等提供了保障。
|
||||
|
||||
通过 GitLab 工作流,可以很方便的[提升](https://about.gitlab.com/2016/09/13/gitlab-master-plan/)团队的工作效率以及凝聚力。这种提升,从引入一个新的项目开始,一直到发布这个项目,成为一个产品都有所体现。这就是我们所说的“如何通过最快的速度把一个点子在 10 步之内变成一个产品”。
|
||||
|
||||
![FROM IDEA TO PRODUCTION IN 10 STEPS](https://about.gitlab.com/images/blogimages/idea-to-production-10-steps.png)
|
||||
|
||||
#### 软件开发阶段
|
||||
|
||||
一般情况下,软件开发经过 10 个主要阶段;GitLab 为这 10 个阶段依次提供了解决方案:
|
||||
|
||||
1. **IDEA**: 每一个从点子开始的项目,通常来源于一次闲聊。在这个阶段,GitLab 集成了 [Mattermost][44]。
|
||||
2. **ISSUE**: 最有效的讨论一个点子的方法,就是为这个点子建立一个工单讨论。你的团队和你的合作伙伴可以在 <ruby>工单追踪器<rt>issue tracker</rt></ruby> 中帮助你去提升这个点子
|
||||
3. **PLAN**: 一旦讨论得到一致的同意,就是开始编码的时候了。但是等等!首先,我们需要优先考虑组织我们的工作流。对于此,我们可以使用 <ruby>工单看板<rt>Issue Board</rt></ruby>。
|
||||
4. **CODE**: 现在,当一切准备就绪,我们可以开始写代码了。
|
||||
5. **COMMIT**: 当我们为我们的初步成果欢呼的时候,我们就可以在版本控制下,提交代码到功能分支了。
|
||||
6. **TEST**: 通过 [GitLab CI][41],我们可以运行脚本来构建和测试我们的应用。
|
||||
7. **REVIEW**: 一旦脚本成功运行,我们测试和构建成功,我们就可以进行 <ruby>代码复审<rt>code review</rt></ruby> 以及批准。
|
||||
8. **STAGING:**: 现在是时候[将我们的代码部署到演示环境][39]来检查一下,看看是否一切就像我们预估的那样顺畅——或者我们可能仍然需要修改。
|
||||
9. **PRODUCTION**: 当一切都如预期,就是[部署到生产环境][38]的时候了!
|
||||
10. **FEEDBACK**: 现在是时候返回去看我们项目中需要提升的部分了。我们使用[<ruby>周期分析<rt> Cycle Analytics</rt></ruby>][37]来对当前项目中关键的部分进行的反馈。
|
||||
|
||||
简单浏览这些步骤,我们可以发现,提供强大的工具来支持这些步骤是十分重要的。在接下来的部分,我们为 GitLab 的可用工具提供一个简单的概览。
|
||||
|
||||
### GitLab 工单追踪器
|
||||
|
||||
GitLab 有一个强大的工单追溯系统,在使用过程中,允许你和你的团队,以及你的合作者分享和讨论建议。
|
||||
|
||||
![issue tracker - view list](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/issue-tracker-list-view.png)
|
||||
|
||||
工单是 GitLab 工作流的第一个重要重要特性。[以工单的讨论为开始][95]; 跟踪新点子的改变是一个最好的方式。
|
||||
|
||||
这十分有利于:
|
||||
|
||||
* 讨论点子
|
||||
* 提交功能建议
|
||||
* 提问题
|
||||
* 提交错误和故障
|
||||
* 获取支持
|
||||
* 精细化新代码的引入
|
||||
|
||||
每一个在 GitLab 上部署的项目都有一个工单追踪器。找到你的项目中的 **Issues** > **New issue** 来创建一个新的工单。建立一个标题来总结要被讨论的主题,并且使用 [Markdown][94] 来形容它。看看下面的“专业技巧”来加强你的工单描述。
|
||||
|
||||
GitLab 工单追踪器提供了一个额外的实用功能,使得步骤变得更佳易于管理和考虑。下面的部分仔细描述了它。
|
||||
|
||||
![new issue - additional settings](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/issue-features-view.png)
|
||||
|
||||
#### 秘密工单
|
||||
|
||||
无论何时,如果你仅仅想要在团队中讨论这个工单,你可以使[该工单成为秘密的][92]。即使你的项目是公开的,你的工单也会被保密起来。当一个不是本项目成员的人,就算是 [报告人级别][01],想要访问工单的地址时,浏览器也会返回一个 404 错误。
|
||||
|
||||
#### 截止日期
|
||||
|
||||
每一个工单允许你填写一个[截止日期][90]。有些团队工作时间表安排紧凑,以某种方式去设置一个截止日期来解决问题,是有必要的。这些都可以通过截止日期这一功能实现。
|
||||
|
||||
当你对一个多任务项目有截止日期的时候——比如说,一个新的发布活动、项目的启动,或者按阶段追踪任务——你可以使用[里程碑][89]。
|
||||
|
||||
#### 受托者
|
||||
|
||||
要让某人处理某个工单,可以将其分配给他。你可以任意修改被分配者,直到满足你的需求。这个功能的想法是,一个受托者本身对这个工单负责,直到其将这个工单重新赋予其他人。
|
||||
|
||||
这也可以用于按受托者筛选工单。
|
||||
|
||||
#### 标签
|
||||
|
||||
GitLab 标签也是 GitLab 流的一个重要组成部分。你可以使用它们来分类你的工单,在工作流中定位,以及通过[优先级标签][88]来安装优先级组织它们。
|
||||
|
||||
标签使得你与[GitLab 工单看板][87]协同工作,加快工程进度以及组织你的工作流。
|
||||
|
||||
**新功能:** 你可以创建[组标签][86]。它可以使得在每一个项目组中使用相同的标签。
|
||||
|
||||
#### 工单权重
|
||||
|
||||
你可以添加个[工单权重][85]使得一个工单重要性表现的更为清晰。01 - 03 表示工单不是特别重要,07 - 09 表示十分重要,04 - 06 表示程度适中。此外,你可以与你的团队自行定义工单重要性的指标。
|
||||
|
||||
注:该功能仅可用于 GitLab 企业版和 GitLab.com 上。
|
||||
|
||||
#### GitLab 工单看板
|
||||
|
||||
在项目中,[GitLab 工单看板][84]是一个用于计划以及组织你的工单,使之符合你的项目工作流的工具。
|
||||
|
||||
看板包含了与其相关的相应标签,每一个列表包含了相关的被标记的工单,并且以卡片的形式展示出来。
|
||||
|
||||
这些卡片可以在列表之间移动,被移动的卡片,其标签将会依据你移动的位置相应更新到列表上。
|
||||
|
||||
![GitLab Issue Board](https://about.gitlab.com/images/blogimages/designing-issue-boards/issue-board.gif)
|
||||
|
||||
**新功能:** 你也可以通过点击列表上方的“+”按钮在看板右边创建工单。当你这么做的时候,这个工单将会自动添加与列表相关的标签。
|
||||
|
||||
**新功能:** 我们[最近推出了][83] 每一个 GitLab 项目拥有**多个工单看板**的功能(仅存在于 [GitLab 企业版][82]);这是为不同的工作流组织你的工单的好方法。
|
||||
|
||||
![Multiple Issue Boards](https://about.gitlab.com/images/8_13/m_ib.gif)
|
||||
|
||||
### 通过 GitLab 进行代码复审
|
||||
|
||||
在工单追踪器中,讨论了新的提议之后,就是在代码上做工作的时候了。你在本地书写代码,一旦你完成了你的第一个版本,提交你的代码并且推送到你的 GitLab 仓库。你基于 Git 的管理策略可以在 [GitLab 流][81]中被提升。
|
||||
|
||||
#### 第一次提交
|
||||
|
||||
在你的第一次提交信息中,你可以添加涉及到工单号在其中。通过这样做你可以将两个阶段的开发工作流链接起来:工单本身以及关于这个工单的第一次提交。
|
||||
|
||||
这样做,如果你提交的代码和工单属于同一个项目,你可以简单的添加 `#xxx` 到提交信息中(LCTT 译注:`git commit message`),`xxx`是一个工单号。如果它们不在一个项目中,你可以添加整个工单的整个URL(`https://gitlab.com/<username>/<projectname>/issues/<xxx>`)。
|
||||
|
||||
```
|
||||
git commit -m "this is my commit message. Ref #xxx"
|
||||
```
|
||||
|
||||
或者
|
||||
|
||||
```
|
||||
git commit -m "this is my commit message. Related to https://gitlab.com/<username>/<projectname>/issues/<xxx>"
|
||||
```
|
||||
|
||||
当然,你也可以替换 `gitlab.com`,以你自己的 GitLab 实例来替换这个 URL。
|
||||
|
||||
**注:** 链接工单和你的第一次提交是为了通过 [GitLab 周期分析][80]追踪你的进展。这将会衡量计划执行该工单所采取的时间,即创建工单与第一次提交的间隔时间。
|
||||
|
||||
#### 合并请求
|
||||
|
||||
一旦将你的改动提交到功能分支,GitLab 将识别该修改,并且建议你提交一次<ruby>合并请求<rt>Merge Request</rt></ruby>(MR)。
|
||||
|
||||
每一次 MR 都会有一个标题(这个标题总结了这次的改动)并且一个用 [Markdown][79] 书写的描述。在描述中,你可以简单的描述该 MR 做了什么,提及任何工单以及 MR(在它们之间创建联系),并且,你也可以添加个[关闭工单模式][78],当该 MR 被**合并**的时候,相关联的工单就会被关闭。
|
||||
|
||||
例如:
|
||||
|
||||
```
|
||||
## 增加一个新页面
|
||||
|
||||
这个 MR 将会为这个项目创建一个包含该 app 概览的 `readme.md`。
|
||||
|
||||
Closes #xxx and https://gitlab.com/<username>/<projectname>/issues/<xxx>
|
||||
|
||||
预览:
|
||||
|
||||
![预览新页面](#image-url)
|
||||
|
||||
cc/ @Mary @Jane @John
|
||||
```
|
||||
|
||||
当你创建一个如上的带有描述的 MR,它将会:
|
||||
|
||||
* 当合并时,关闭包括工单 `#xxx` 以及 `https://gitlab.com/<username>/<projectname>/issues/<xxx>`
|
||||
* 展示一张图片
|
||||
* 通过邮件提醒用户 `@Mary`、`@Jane`,以及给 `@John`
|
||||
|
||||
你可以分配这个 MR 给你自己,直到你完成你的工作,然后把它分配给其他人来做一次代码复审。如果有必要的话,这个 MR 可以被重新分配多次,直到你覆盖你所需要的所有复审。
|
||||
|
||||
它也可以被标记,并且添加一个[里程碑][77]来促进管理。
|
||||
|
||||
当你从图形界面而不是命令行添加或者修改一个文件并且提交一个新的分支时,也很容易创建一个新的 MR,仅仅需要标记一下复选框,“以这些改变开始一个新的合并请求”,然后,一旦你提交你的改动,GitLab 将会自动创建一个新的 MR。
|
||||
|
||||
![commit to a feature branch and add a new MR from the UI](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/start-new-mr-edit-from-ui.png)
|
||||
|
||||
**注:** 添加[关闭工单样式][76]到你的 MR 以便可以使用 [GitLab 周期分析][75]追踪你的项目进展,是十分重要的。它将会追踪“CODE”阶段,衡量第一次提交及创建一个相关的合并请求所间隔的时间。
|
||||
|
||||
**新功能:** 我们已经开发了[审查应用][74],这是一个可以让你部署你的应用到一个动态的环境中的新功能,在此你可以按分支名字、每个合并请求来预览改变。参看这里的[可用示例][73]。
|
||||
|
||||
#### WIP MR
|
||||
|
||||
WIP MR 含义是 **在工作过程中的合并请求**,是一个我们在 GitLab 中避免 MR 在准备就绪前被合并的技术。只需要添加 `WIP:` 在 MR 的标题开头,它将不会被合并,除非你把 `WIP:` 删除。
|
||||
|
||||
当你改动已经准备好被合并,编辑工单来手动删除 `WIP:` ,或者使用就像如下 MR 描述下方的快捷方式。
|
||||
|
||||
![WIP MR click to remove WIP from the title](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-wip-mr.png)
|
||||
|
||||
**新功能:** `WIP` 模式可以通过[斜线命令][71] `/wip` [快速添加到合并请求中][72]。只需要在评论或者 MR 描述中输入它并提交即可。
|
||||
|
||||
#### 复审
|
||||
|
||||
一旦你创建一个合并请求,就是你开始从你的团队以及合作方收取反馈的时候了。使用图形界面中的差异比较功能,你可以简单的添加行内注释,以及回复或者解决它们。
|
||||
|
||||
你也可以通过点击行号获取每一行代码的链接。
|
||||
|
||||
在图形界面中可以看到提交历史,通过提交历史,你可以追踪文件的每一次改变。你可以以行内差异或左右对比的方式浏览它们。
|
||||
|
||||
![code review in MRs at GitLab](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-code-review.png)
|
||||
|
||||
**新功能:** 如果你遇到合并冲突,可以快速地[通过图形界面来解决][70],或者依据你的需要修改文件来修复冲突。
|
||||
|
||||
![mr conflict resolution](https://about.gitlab.com/images/8_13/inlinemergeconflictresolution.gif)
|
||||
|
||||
### 构建、测试以及发布
|
||||
|
||||
[GitLab CI][69] 是一个强大的内建工具,其作用是[持续集成、持续发布以及持续分发][58],它可以按照你希望的运行一些脚本。它的可能性是无止尽的:你可以把它看做是自己运行的命令行。
|
||||
|
||||
它完全是通过一个名为 `.gitlab-ci.yml` 的 YAML 文件设置的,其放置在你的项目仓库中。使用 Web 界面简单的添加一个文件,命名为 `.gitlab-ci.yml` 来触发一个下拉菜单,为不同的应用选择各种 CI 模版。
|
||||
|
||||
![GitLab CI templates - dropdown menu](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-ci-template.png)
|
||||
|
||||
#### Koding
|
||||
|
||||
Use GitLab's [Koding integration][67] to run your entire development environment in the cloud. This means that you can check out a project or just a merge request in a full-fledged IDE with the press of a button.
|
||||
|
||||
可以使用 GitLab 的 [Koding 集成][67]功能在云端运行你的整个云端开发环境。这意味着你可以轻轻一键即可在一个完整的 IDE 中检出以个项目,或者合并一个请求。
|
||||
|
||||
#### 使用案例
|
||||
|
||||
GitLab CI 的使用案例:
|
||||
|
||||
* 用它来[构建][36]任何[静态网站生成器][35],并且通过 [GitLab Pages][34] 发布你的网站。
|
||||
* 用它来[发布你的网站][33] 到 `staging` 以及 `production` [环境][32]。
|
||||
* 用它来[构建一个 iOS 应用][31]。
|
||||
* 用它来[构建和发布你的 Docker 镜像][30]到 [GitLab 容器注册库][29]。
|
||||
|
||||
我们已经准备一大堆 [GitLab CI 样例工程][66]作为您的指南。看看它们吧!
|
||||
|
||||
### 反馈:周期分析
|
||||
|
||||
当你遵循 GitLab 工作流进行工作,你的团队从点子到产品,在每一个[过程的关键部分][64],你将会在下列时间获得一个 [GitLab 周期分析][65]的反馈:
|
||||
|
||||
* **Issue**: 从创建一个工单,到分配这个工单给一个里程碑或者添加工单到你的工单看板的时间。
|
||||
* **Plan**: 从给工单分配一个里程碑或者把它添加到工单看板,到推送第一次提交的时间。
|
||||
* **Code**: 从第一次提交到提出该合并请求的时间。
|
||||
* **Test**: CI 为了相关合并请求而运行整个过程的时间。
|
||||
* **Review**: 从创建一个合并请求到合并它的时间。
|
||||
* **Staging**: 从合并到发布成为产品的时间。
|
||||
* **Production(Total)**: 从创建工单到把代码发布成[产品][28]的时间。
|
||||
|
||||
### 加强
|
||||
|
||||
#### 工单以及合并请求模版
|
||||
|
||||
[工单以及合并请求模版][63]允许你为你的项目去定义一个特定内容的工单模版和合并请求的描述字段。
|
||||
|
||||
你可以以 [Markdown][62] 形式书写它们,并且把它们加入仓库的默认分支。当创建工单或者合并请求时,可以通过下拉菜单访问它们。
|
||||
|
||||
它们节省了您在描述工单和合并请求的时间,并标准化了需要持续跟踪的重要信息。它确保了你需要的一切都在你的掌控之中。
|
||||
|
||||
你可以创建许多模版,用于不同的用途。例如,你可以有一个提供功能建议的工单模版,或者一个 bug 汇报的工单模版。在 [GitLab CE project][61] 中寻找真实的例子吧!
|
||||
|
||||
![issues and MR templates - dropdown menu screenshot](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/issues-choose-template.png)
|
||||
|
||||
#### 里程碑
|
||||
|
||||
[里程碑][60] 是 GitLab 中基于共同的目标、详细的日期追踪你队伍工作的最好工具。
|
||||
|
||||
不同情况下的目的是不同的,但是大致是相同的:你有为了达到特定的目标的工单的集合以及正在编码的合并请求。
|
||||
|
||||
这个目标基本上可以是任何东西——用来结合团队的工作,在一个截止日期前完成一些事情。例如,发布一个新的版本,启动一个新的产品,在某个日期前完成,或者按季度收尾一些项目。
|
||||
|
||||
![milestone dashboard](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-milestone.png)
|
||||
|
||||
### 专业技巧
|
||||
|
||||
#### 工单和 MR
|
||||
|
||||
* 在工单和 MR 的描述中:
|
||||
* 输入 `#` 来触发一个已有工单的下拉列表
|
||||
* 输入 `!` 来触发一个已有 MR 的下拉列表
|
||||
* 输入 `/` 来触发[斜线命令][4]
|
||||
* 输入 `:` 来出发 emoji 表情 (也支持行中评论)
|
||||
* 通过按钮“附加文件”来添加图片(jpg、png、gif) 和视频到行内评论
|
||||
* 通过 [GitLab Webhooks][26] [自动应用标签][27]
|
||||
* [构成引用][24]: 使用语法 `>>>` 来开始或者结束一个引用
|
||||
|
||||
```
|
||||
>>>
|
||||
Quoted text
|
||||
|
||||
Another paragraph
|
||||
>>>
|
||||
```
|
||||
* 创建[任务列表][23]:
|
||||
|
||||
```
|
||||
- [ ] Task 1
|
||||
- [ ] Task 2
|
||||
- [ ] Task 3
|
||||
```
|
||||
|
||||
##### 订阅
|
||||
|
||||
你是否发现你有一个工单或者 MR 想要追踪?展开你的右边的导航,点击[订阅][59],你就可以在随时收到一个评论的提醒。要是你想要一次订阅多个工单和 MR?使用[批量订阅][58]。
|
||||
|
||||
##### 添加代办
|
||||
|
||||
除了一直留意工单和 MR,如果你想要对它预先做点什么,或者不管什么时候你想要在 GitLab 代办列表中添加点什么,点击你右边的导航,并且[点击**添加代办**][57]。
|
||||
|
||||
##### 寻找你的工单和 MR
|
||||
|
||||
当你寻找一个在很久以前由你开启的工单或 MR——它们可能数以十计、百计、甚至千计——所以你很难找到它们。打开你左边的导航,并且点击**工单**或者**合并请求**,你就会看到那些分配给你的。同时,在那里或者任何工单追踪器里,你可以通过作者、分配者、里程碑、标签以及重要性来过滤工单,也可以通过搜索所有不同状态的工单,例如开启的、合并的,关闭的等等。
|
||||
|
||||
#### 移动工单
|
||||
|
||||
一个工单在一个错误的项目中结束了?不用担心,点击**Edit**,然后[移动工单][56]到正确的项目。
|
||||
|
||||
#### 代码片段
|
||||
|
||||
你经常在不同的项目以及文件中使用一些相同的代码段和模版吗?创建一个代码段并且使它在你需要的时候可用。打开左边导航栏,点击**[Snipptes][25]**。所有你的片段都会在那里。你可以把它们设置成公开的,内部的(仅为 GitLab 注册用户提供),或者私有的。
|
||||
|
||||
![Snippets - screenshot](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-code-snippet.png)
|
||||
|
||||
### GitLab 工作流用户案例概要
|
||||
|
||||
作为总结,让我们把所有东西聚在一起理顺一下。不必担心,这十分简单。
|
||||
|
||||
让我们假设:你工作于一个专注于软件开发的公司。你创建了一个新的工单,这个工单是为了开发一个新功能,实施于你的一个应用中。
|
||||
|
||||
**标签策略**
|
||||
|
||||
为了这个应用,你已经创建了几个标签,“讨论”、“后端”、“前端”、“正在进行”、“展示”、“就绪”、“文档”、“营销”以及“产品”。所有都已经在工单看板有它们自己的列表。你的当前的工单已经有了标签“讨论”。
|
||||
|
||||
在工单追踪器中的讨论达成一致之后,你的后端团队开始在工单上工作,所以他们把这个工单的标签从“讨论”移动到“后端”。第一个开发者开始写代码,并且把这个工单分配给自己,增加标签“正在进行”。
|
||||
|
||||
**编码 & 提交**
|
||||
|
||||
在他的第一次提交的信息中,他提及了他的工单编号。在工作后,他把他的提交推送到一个功能分支,并且创建一个新的合并请求,在 MR 描述中,包含工单关闭模式。他的团队复审了他的代码并且保证所有的测试和建立都已经通过。
|
||||
|
||||
**使用工单看板**
|
||||
|
||||
一旦后端团队完成了他们的工作,他们就删除“正在进行”标签,并且把工单从“后端”移动到“前端”看板。所以,前端团队接到通知,这个工单已经为他们准备好了。
|
||||
|
||||
**发布到演示**
|
||||
|
||||
当一个前端开发者开始在该工单上工作,他(她)增加一个标签“正在进行”,并且把这个工单重新分配给自己。当工作完成,该实现将会被发布到一个**演示**环境。标签“正在进行”就会被删除,然后在工单看板里,工单卡被移动到“演示”列表中。
|
||||
|
||||
**团队合作**
|
||||
|
||||
最后,当新功能成功实现,你的团队把它移动到“就绪”列表。
|
||||
|
||||
然后,就是你的技术文档编写团队的时间了,他们为新功能书写文档。一旦某个人完成书写,他添加标签“文档”。同时,你的市场团队开始启动并推荐该功能,所以某个人添加“市场”。当技术文档书写完毕,书写者删除标签“文档”。一旦市场团队完成他们的工作,他们将工单从“市场”移动到“生产”。
|
||||
|
||||
**部署到生产环境**
|
||||
|
||||
最后,你将会成为那个为新版本负责的人,合并“合并请求”并且将新功能部署到**生产**环境,然后工单的状态转变为**关闭**。
|
||||
|
||||
**反馈**
|
||||
|
||||
通过[周期分析][55],你和你的团队节省了如何从点子到产品的时间,并且开启另一个工单,来讨论如何将这个过程进一步提升。
|
||||
|
||||
### 总结
|
||||
|
||||
GitLab 工作流通过一个单一平台帮助你的团队加速从点子到生产的改变:
|
||||
|
||||
* 它是**有效的**:因为你可以获取你想要的结果
|
||||
* 它是**高效的**:因为你可以用最小的努力和成本达到最大的生产力
|
||||
* 它是**高产的**:因为你可以非常有效的计划和行动
|
||||
* 它是**简单的**:因为你不需要安装不同的工具去完成你的目的,仅仅需要 GitLab
|
||||
* 它是**快速的**:因为你不需要在多个平台间跳转来完成你的工作
|
||||
|
||||
每一个月的 22 号都会有一个新的 GitLab 版本释出,让它在集成软件开发解决方案上变得越来越好,让团队可以在一个单一的、唯一的界面下一起工作。
|
||||
|
||||
在 GitLab,每个人都可以奉献!多亏了我们强大的社区,我们获得了我们想要的。并且多亏了他们,我们才能一直为你提供更好的产品。
|
||||
|
||||
还有什么问题和反馈吗?请留言,或者在推特上@我们[@GitLab][54]!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/
|
||||
|
||||
作者:[Marcia Ramos][a]
|
||||
译者:[svtter](https://github.com/svtter)
|
||||
校对:[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://twitter.com/XMDRamos
|
||||
[1]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#search-for-your-issues-and-mrs
|
||||
[2]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#add-to-do
|
||||
[3]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#subscribe
|
||||
[4]:https://docs.gitlab.com/ce/user/project/slash_commands.html
|
||||
[5]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#code-snippets
|
||||
[6]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#moving-issues
|
||||
[7]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#for-both-issues-and-mrs
|
||||
[8]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#milestones
|
||||
[9]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#issue-and-mr-templates
|
||||
[10]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#use-cases
|
||||
[11]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#koding
|
||||
[12]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#review
|
||||
[13]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#wip-mr
|
||||
[14]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#merge-request
|
||||
[15]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#first-commit
|
||||
[16]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-board
|
||||
[17]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#issue-weight
|
||||
[18]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#labels
|
||||
[19]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#assignee
|
||||
[20]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#due-dates
|
||||
[21]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#confidential-issues
|
||||
[22]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#stages-of-software-development
|
||||
[23]:https://docs.gitlab.com/ee/user/markdown.html#task-lists
|
||||
[24]:https://about.gitlab.com/2016/07/22/gitlab-8-10-released/#blockquote-fence-syntax
|
||||
[25]:https://gitlab.com/dashboard/snippets
|
||||
[26]:https://docs.gitlab.com/ce/web_hooks/web_hooks.html
|
||||
[27]:https://about.gitlab.com/2016/08/19/applying-gitlab-labels-automatically/
|
||||
[28]:https://docs.gitlab.com/ce/ci/yaml/README.html#environment
|
||||
[29]:https://about.gitlab.com/2016/05/23/gitlab-container-registry/
|
||||
[30]:https://about.gitlab.com/2016/08/11/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/
|
||||
[31]:https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/
|
||||
[32]:https://docs.gitlab.com/ce/ci/yaml/README.html#environment
|
||||
[33]:https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/
|
||||
[34]:https://pages.gitlab.io/
|
||||
[35]:https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/
|
||||
[36]:https://about.gitlab.com/2016/04/07/gitlab-pages-setup/
|
||||
[37]:https://about.gitlab.com/solutions/cycle-analytics/
|
||||
[38]:https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/
|
||||
[39]:https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/
|
||||
[40]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-code-review
|
||||
[41]:https://about.gitlab.com/gitlab-ci/
|
||||
[42]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-board
|
||||
[43]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-tracker
|
||||
[44]:https://about.gitlab.com/2015/08/18/gitlab-loves-mattermost/
|
||||
[45]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#conclusions
|
||||
[46]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow-use-case-scenario
|
||||
[47]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#pro-tips
|
||||
[48]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#enhance
|
||||
[49]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#feedback
|
||||
[50]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#build-test-and-deploy
|
||||
[51]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#code-review-with-gitlab
|
||||
[52]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-tracker
|
||||
[53]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow
|
||||
[54]:https://twitter.com/gitlab
|
||||
[55]:https://about.gitlab.com/solutions/cycle-analytics/
|
||||
[56]:https://about.gitlab.com/2016/03/22/gitlab-8-6-released/#move-issues-to-other-projects
|
||||
[57]:https://about.gitlab.com/2016/06/22/gitlab-8-9-released/#manually-add-todos
|
||||
[58]:https://about.gitlab.com/2016/07/22/gitlab-8-10-released/#bulk-subscribe-to-issues
|
||||
[59]:https://about.gitlab.com/2016/03/22/gitlab-8-6-released/#subscribe-to-a-label
|
||||
[60]:https://about.gitlab.com/2016/08/05/feature-highlight-set-dates-for-issues/#milestones
|
||||
[61]:https://gitlab.com/gitlab-org/gitlab-ce/issues/new
|
||||
[62]:https://docs.gitlab.com/ee/user/markdown.html
|
||||
[63]:https://docs.gitlab.com/ce/user/project/description_templates.html
|
||||
[64]:https://about.gitlab.com/2016/09/21/cycle-analytics-feature-highlight/
|
||||
[65]:https://about.gitlab.com/solutions/cycle-analytics/
|
||||
[66]:https://docs.gitlab.com/ee/ci/examples/README.html
|
||||
[67]:https://about.gitlab.com/2016/08/22/gitlab-8-11-released/#koding-integration
|
||||
[68]:https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/
|
||||
[69]:https://about.gitlab.com/gitlab-ci/
|
||||
[70]:https://about.gitlab.com/2016/08/22/gitlab-8-11-released/#merge-conflict-resolution
|
||||
[71]:https://docs.gitlab.com/ce/user/project/slash_commands.html
|
||||
[72]:https://about.gitlab.com/2016/10/22/gitlab-8-13-released/#wip-slash-command
|
||||
[73]:https://gitlab.com/gitlab-examples/review-apps-nginx/
|
||||
[74]:https://about.gitlab.com/2016/10/22/gitlab-8-13-released/#ability-to-stop-review-apps
|
||||
[75]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#feedback
|
||||
[76]:https://docs.gitlab.com/ce/administration/issue_closing_pattern.html
|
||||
[77]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#milestones
|
||||
[78]:https://docs.gitlab.com/ce/administration/issue_closing_pattern.html
|
||||
[79]:https://docs.gitlab.com/ee/user/markdown.html
|
||||
[80]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#feedback
|
||||
[81]:https://about.gitlab.com/2014/09/29/gitlab-flow/
|
||||
[82]:https://about.gitlab.com/free-trial/
|
||||
[83]:https://about.gitlab.com/2016/10/22/gitlab-8-13-released/#multiple-issue-boards-ee
|
||||
[84]:https://about.gitlab.com/solutions/issueboard
|
||||
[85]:https://docs.gitlab.com/ee/workflow/issue_weight.html
|
||||
[86]:https://about.gitlab.com/2016/10/22/gitlab-8-13-released/#group-labels
|
||||
[87]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-board
|
||||
[88]:https://docs.gitlab.com/ee/user/project/labels.html#prioritize-labels
|
||||
[89]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#milestones
|
||||
[90]:https://about.gitlab.com/2016/08/05/feature-highlight-set-dates-for-issues/#due-dates-for-issues
|
||||
[91]:https://docs.gitlab.com/ce/user/permissions.html
|
||||
[92]:https://about.gitlab.com/2016/03/31/feature-highlihght-confidential-issues/
|
||||
[93]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#pro-tips
|
||||
[94]:https://docs.gitlab.com/ee/user/markdown.html
|
||||
[95]:https://about.gitlab.com/2016/03/03/start-with-an-issue/
|
||||
[96]:https://about.gitlab.com/2016/09/13/gitlab-master-plan/
|
||||
[97]:https://about.gitlab.com/2014/09/29/gitlab-flow/
|
@ -1,33 +1,33 @@
|
||||
如何在 CentOS 7 中使用 SSL/TLS 加固 FTP 服务器进行安全文件传输
|
||||
============================================================
|
||||
|
||||
在一开始的设计中,FTP(文件传输协议)是不安全的,意味着它不会加密两台机器之间传输的数据以及用户的凭据。这使得数据和服务器安全面临很大威胁。
|
||||
在一开始的设计中,FTP(文件传输协议)就是不安全的,意味着它不会加密两台机器之间传输的数据以及用户的凭据。这使得数据和服务器安全面临很大威胁。
|
||||
|
||||
在这篇文章中,我们会介绍在 CentOS/RHEL 7 以及 Fedora 中如何在 FTP 服务器中手动启用数据加密服务;我们会介绍使用 SSL/TLS 证书保护 VSFTPD(Very Secure FTP Daemon)服务的各个步骤。
|
||||
|
||||
#### 前提条件:
|
||||
|
||||
1. 你必须已经[在 CentOS 7 中安装和配置 FTP 服务][1]
|
||||
- 你必须已经[在 CentOS 7 中安装和配置 FTP 服务][1] 。
|
||||
|
||||
在我们开始之前,要注意本文中所有命令都以 root 用户运行,否则,如果现在你不是使用 root 用户控制服务器,你可以使用 [sudo 命令][2] 去获取 root 权限。
|
||||
|
||||
### 第一步:生成 SSL/TLS 证书和密钥
|
||||
|
||||
1. 我们首先要在 `/etc/ssl` 目录下创建用于保存 SSL/TLS 证书和密钥文件的子目录:
|
||||
1、 我们首先要在 `/etc/ssl` 目录下创建用于保存 SSL/TLS 证书和密钥文件的子目录:
|
||||
|
||||
```
|
||||
# mkdir /etc/ssl/private
|
||||
```
|
||||
|
||||
2. 然后运行下面的命令为 vsftpd 创建证书和密钥并保存到一个文件中,下面会解析使用的每个标签。
|
||||
2、 然后运行下面的命令为 vsftpd 创建证书和密钥并保存到一个文件中,下面会解析使用的每个选项。
|
||||
|
||||
1. req - 是 X.509 Certificate Signing Request (CSR,证书签名请求)管理的一个命令。
|
||||
2. x509 - X.509 证书数据管理。
|
||||
3. days - 定义证书的有效日期。
|
||||
4. newkey - 指定证书密钥处理器。
|
||||
5. rsa:2048 - RSA 密钥处理器,会生成一个 2048 位的密钥。
|
||||
6. keyout - 设置密钥存储文件。
|
||||
7. out - 设置证书存储文件,注意证书和密钥都保存在一个相同的文件:/etc/ssl/private/vsftpd.pem。
|
||||
1. `req` - 是 X.509 Certificate Signing Request (CSR,证书签名请求)管理的一个命令。
|
||||
2. `x509` - X.509 证书数据管理。
|
||||
3. `days` - 定义证书的有效日期。
|
||||
4. `newkey` - 指定证书密钥处理器。
|
||||
5. `rsa:2048` - RSA 密钥处理器,会生成一个 2048 位的密钥。
|
||||
6. `keyout` - 设置密钥存储文件。
|
||||
7. `out` - 设置证书存储文件,注意证书和密钥都保存在一个相同的文件:/etc/ssl/private/vsftpd.pem。
|
||||
|
||||
```
|
||||
# openssl req -x509 -nodes -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem -days 365 -newkey rsa:2048
|
||||
@ -47,7 +47,7 @@ Email Address []:admin@tecmint.com
|
||||
|
||||
### 第二步:配置 VSFTPD 使用 SSL/TLS
|
||||
|
||||
3. 在我们进行任何 VSFTPD 配置之前,首先开放 990 和 40000-50000 端口,以便在 VSFTPD 配置文件中分别定义 TLS 连接的端口和被动端口的端口范围:
|
||||
3、 在我们进行任何 VSFTPD 配置之前,首先开放 990 和 40000-50000 端口,以便在 VSFTPD 配置文件中分别定义 TLS 连接的端口和被动端口的端口范围:
|
||||
|
||||
```
|
||||
# firewall-cmd --zone=public --permanent --add-port=990/tcp
|
||||
@ -55,7 +55,7 @@ Email Address []:admin@tecmint.com
|
||||
# firewall-cmd --reload
|
||||
```
|
||||
|
||||
4. 现在,打开 VSFTPD 配置文件并在文件中指定 SSL 的详细信息:
|
||||
4、 现在,打开 VSFTPD 配置文件并在文件中指定 SSL 的详细信息:
|
||||
|
||||
```
|
||||
# vi /etc/vsftpd/vsftpd.conf
|
||||
@ -70,14 +70,14 @@ ssl_sslv2=NO
|
||||
ssl_sslv3=NO
|
||||
```
|
||||
|
||||
5. 然后,添加下面的行定义 SSL 证书和密钥文件的位置:
|
||||
5、 然后,添加下面的行来定义 SSL 证书和密钥文件的位置:
|
||||
|
||||
```
|
||||
rsa_cert_file=/etc/ssl/private/vsftpd.pem
|
||||
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
|
||||
```
|
||||
|
||||
6. 下面,我们要阻止匿名用户使用 SSL,然后强制所有非匿名用户登录使用安全的 SSL 连接进行数据传输和登录过程中的密码发送:
|
||||
6、 下面,我们要阻止匿名用户使用 SSL,然后强制所有非匿名用户登录使用安全的 SSL 连接进行数据传输和登录过程中的密码发送:
|
||||
|
||||
```
|
||||
allow_anon_ssl=NO
|
||||
@ -85,7 +85,7 @@ force_local_data_ssl=YES
|
||||
force_local_logins_ssl=YES
|
||||
```
|
||||
|
||||
7. 另外,我们还可以添加下面的选项增强 FTP 服务器的安全性。当选项 `require_ssl_reuse` 被设置为 `YES` 时,要求所有 SSL 数据连接都显示 SSL 会话重用;表明它们知道与控制频道相同的主机密码。
|
||||
7、 另外,我们还可以添加下面的选项增强 FTP 服务器的安全性。当选项 `require_ssl_reuse` 被设置为 `YES` 时,要求所有 SSL 数据连接都会重用 SSL 会话;这样它们会知道控制通道的主密码。
|
||||
|
||||
因此,我们需要把它关闭。
|
||||
|
||||
@ -93,19 +93,19 @@ force_local_logins_ssl=YES
|
||||
require_ssl_reuse=NO
|
||||
```
|
||||
|
||||
另外,我们还要用 `ssl_ciphers` 选项选择 VSFTPD 允许用于加密 SSL 连接的 SSL 密码。这可以大大限制尝试使用在漏洞中发现的特定密码的攻击者:
|
||||
另外,我们还要用 `ssl_ciphers` 选项选择 VSFTPD 允许用于加密 SSL 连接的 SSL 算法。这可以极大地限制那些尝试发现使用存在缺陷的特定算法的攻击者:
|
||||
|
||||
```
|
||||
ssl_ciphers=HIGH
|
||||
```
|
||||
|
||||
8. 现在,设置被动端口的端口范围(最小和最大端口)。
|
||||
8、 现在,设置被动端口的端口范围(最小和最大端口)。
|
||||
```
|
||||
pasv_min_port=40000
|
||||
pasv_max_port=50000
|
||||
```
|
||||
|
||||
9. 选择性启用 `debug_ssl` 选项以允许 SSL 调试,意味着 OpenSSL 连接诊断会被记录到 VSFTPD 日志文件:
|
||||
9、 选择性启用 `debug_ssl` 选项以允许 SSL 调试,这意味着 OpenSSL 连接诊断会被记录到 VSFTPD 日志文件:
|
||||
|
||||
```
|
||||
debug_ssl=YES
|
||||
@ -119,7 +119,7 @@ debug_ssl=YES
|
||||
|
||||
### 第三步:用 SSL/TLS 连接测试 FTP 服务器
|
||||
|
||||
10. 完成上面的所有配置之后,像下面这样通过在命令行中尝试使用 FTP 测试 VSFTPD 是否使用 SSL/TLS 连接:
|
||||
10、 完成上面的所有配置之后,像下面这样通过在命令行中尝试使用 FTP 测试 VSFTPD 是否使用 SSL/TLS 连接:
|
||||
|
||||
```
|
||||
# ftp 192.168.56.10
|
||||
@ -131,11 +131,12 @@ Login failed.
|
||||
421 Service not available, remote server has closed connection
|
||||
ftp>
|
||||
```
|
||||
|
||||
[
|
||||
![验证 FTP SSL 安全连接](http://www.tecmint.com/wp-content/uploads/2017/02/Verify-FTP-Secure-Connection.png)
|
||||
][3]
|
||||
|
||||
验证 FTP SSL 安全连接
|
||||
*验证 FTP SSL 安全连接*
|
||||
|
||||
从上面的截图中,我们可以看到这里有个错误提示我们 VSFTPD 只允许用户从支持加密服务的客户端登录。
|
||||
|
||||
@ -143,7 +144,7 @@ ftp>
|
||||
|
||||
### 第四步:安装 FileZilla 以便安全地连接到 FTP 服务器
|
||||
|
||||
11. FileZilla 是一个时尚、流行且重要的交叉平台 FTP 客户端,它默认支持 SSL/TLS 连接。
|
||||
11、 FileZilla 是一个现代化、流行且重要的跨平台的 FTP 客户端,它默认支持 SSL/TLS 连接。
|
||||
|
||||
要在 Linux 上安装 FileZilla,可以运行下面的命令:
|
||||
|
||||
@ -154,7 +155,7 @@ ftp>
|
||||
$ sudo apt-get install filezilla
|
||||
```
|
||||
|
||||
12. 当安装完成后(或者你已经安装了该软件),打开它,选择 File=>Sites Manager 或者按 `Ctrl + S` 打开 Site Manager 界面。
|
||||
12、 当安装完成后(或者你已经安装了该软件),打开它,选择 File => Sites Manager 或者按 `Ctrl + S` 打开 Site Manager 界面。
|
||||
|
||||
点击 New Site 按钮添加一个新的站点/主机连接详细信息。
|
||||
|
||||
@ -162,7 +163,7 @@ $ sudo apt-get install filezilla
|
||||
![在 FileZilla 中添加新 FTP 站点](http://www.tecmint.com/wp-content/uploads/2017/02/Add-New-FTP-Site-in-Filezilla.png)
|
||||
][4]
|
||||
|
||||
在 FileZilla 中添加新 FTP 站点
|
||||
*在 FileZilla 中添加新 FTP 站点*
|
||||
|
||||
13. 下一步,像下面这样设置主机/站点名称、添加 IP 地址、定义使用的协议、加密和登录类型(使用你自己情况的值):
|
||||
|
||||
@ -177,15 +178,15 @@ User: username
|
||||
![在 Filezilla 中添加 FTP 服务器详细信息](http://www.tecmint.com/wp-content/uploads/2017/02/Add-FTP-Server-Details-in-Filezilla.png)
|
||||
][5]
|
||||
|
||||
在 Filezilla 中添加 FTP 服务器详细信息
|
||||
*在 Filezilla 中添加 FTP 服务器详细信息*
|
||||
|
||||
14. 然后点击 Connect,再次输入密码,然后验证用于 SSL/TLS 连接的证书,再一次点击 `OK` 连接到 FTP 服务器:
|
||||
14、 然后点击 Connect,再次输入密码,然后验证用于 SSL/TLS 连接的证书,再一次点击 `OK` 连接到 FTP 服务器:
|
||||
|
||||
[
|
||||
![验证 FTP SSL 证书](http://www.tecmint.com/wp-content/uploads/2017/02/Verify-FTP-SSL-Certificate.png)
|
||||
][6]
|
||||
|
||||
验证 FTP SSL 证书
|
||||
*验证 FTP SSL 证书*
|
||||
|
||||
到了这里,我们应该使用 TLS 连接成功地登录到了 FTP 服务器,在下面的界面中检查连接状态部分获取更多信息。
|
||||
|
||||
@ -193,15 +194,15 @@ User: username
|
||||
![通过 TLS/SSL 连接到 FTP 服务器](http://www.tecmint.com/wp-content/uploads/2017/02/connected-to-ftp-server-with-tls.png)
|
||||
][7]
|
||||
|
||||
通过 TLS/SSL 连接到 FTP 服务器
|
||||
*通过 TLS/SSL 连接到 FTP 服务器*
|
||||
|
||||
15. 最后,在文件目录尝试 [从本地传输文件到 FTP 服务器][8],看 FileZilla 界面后面的部分查看文件传输相关的报告。
|
||||
15、 最后,在文件目录尝试 [从本地传输文件到 FTP 服务器][8],看 FileZilla 界面后面的部分查看文件传输相关的报告。
|
||||
|
||||
[
|
||||
![使用 FTP 安全地传输文件](http://www.tecmint.com/wp-content/uploads/2017/02/Transfer-Files-Securely-Using-FTP.png)
|
||||
][9]
|
||||
|
||||
使用 FTP 安全地传输文件
|
||||
*使用 FTP 安全地传输文件*
|
||||
|
||||
就是这些。记住 FTP 默认是不安全的,除非我们像上面介绍的那样配置它使用 SSL/TLS 连接。在下面的评论框中和我们分享你关于这篇文章/主题的想法吧。
|
||||
|
||||
@ -217,7 +218,7 @@ via: http://www.tecmint.com/secure-vsftpd-using-ssl-tls-on-centos/
|
||||
|
||||
作者:[Aaron Kili][a]
|
||||
译者:[ictlyh](https://github.com/ictlyh)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
校对:[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
@ -1,30 +1,30 @@
|
||||
如何用树莓派搭建一个自己的 web 服务器
|
||||
如何用树莓派搭建个人 web 服务器
|
||||
============================================================
|
||||
|
||||
![How to set up a personal web server with a Raspberry Pi](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/lightbulb_computer_person_general_.png?itok=ZY3UuQQa "How to set up a personal web server with a Raspberry Pi")
|
||||
|
||||
>图片来源 : opensource.com
|
||||
|
||||
个人网络服务器即 “云”,只不过是你拥有和控制它,而不是一个大型公司。
|
||||
个人 Web 服务器即 “云”,只不过是你拥有和控制它,而不是一个大型公司。
|
||||
|
||||
拥有一个自己的云有很多好处,包括定制,免费存储,免费的互联网服务,开源软件的路径,高品质的安全性,完全控制您的内容,快速更改的能力,实验代码的地方等等。 这些好处大部分是无法估量的,但在财务上,这些好处可以为您每个月节省超过 100 美元。
|
||||
拥有一个自己的云有很多好处,包括可定制、免费存储、免费的互联网服务、通往开源软件之路、高安全性、完全控制您的内容、快速更改的能力、实验代码的地方等等。 这些好处大部分是无法估量的,但在财务上,这些好处可以为您每个月节省超过 100 美元。
|
||||
|
||||
![Building your own web server with Raspberry Pi](https://opensource.com/sites/default/files/1-image_by_mitchell_mclaughlin_cc_by-sa_4.0.png "Building your own web server with Raspberry Pi")
|
||||
|
||||
图片来自 Mitchell McLaughlin, CC BY-SA 4.0
|
||||
|
||||
我本可以选择 AWS ,但我更喜欢完全自由且安全性可控,并且我可以学一下这些东西是如何搭建的。
|
||||
|
||||
* 私有主机: 不使用 BlueHost 或 DreamHost
|
||||
* 云存储:不使用 Dropbox, Box, Google Drive, Microsoft Azure, iCloud, 或是 AWS
|
||||
* 内部部署安全
|
||||
* 私有 Web 托管:而非 BlueHost 或 DreamHost
|
||||
* 云存储:而非 Dropbox、Box、Google Drive、Microsoft Azure、iCloud 或是 AWS
|
||||
* 自主部署安全
|
||||
* HTTPS:Let’s Encrypt
|
||||
* 分析: Google
|
||||
* OpenVPN:不需要专有互联网连接 (预计每个月花费 $7)
|
||||
* OpenVPN:不需要专有互联网连接(预计每个月花费 $7)
|
||||
|
||||
我所使用的物品清单:
|
||||
|
||||
* 树莓派 3 代 Model B
|
||||
* MicroSD 卡(推荐使用 32 GB, [兼容树莓派的 SD 卡][a1])
|
||||
* MicroSD 卡(推荐使用 32 GB, [兼容树莓派的 SD 卡][a1])
|
||||
* USB microSD 卡读卡器
|
||||
* 以太网络线
|
||||
* 连接上 Wi-Fi 的路由器
|
||||
@ -37,36 +37,38 @@
|
||||
* 显示器 (支持接入 HDMI)
|
||||
* MacBook Pro
|
||||
|
||||
### 步骤 1: 启动树莓派
|
||||
### 步骤 1: 启动树莓派
|
||||
|
||||
下载最新发布的 Raspbian (树莓派的操作系统)。 [Raspbian Jessie][a6] 的 ZIP 包就可以用 [1]。解压缩或提取下载的文件然后把它拷贝到 SD 卡里。使用 [Pi Filler][a7] 可以让这些过程变得更简单。[下载 Pi Filer 1.3][8] 或最新的版本。解压或提取下载文件之后打开它,你应该会看到这样的提示:
|
||||
下载最新发布的 Raspbian (树莓派的操作系统)。 [Raspbian Jessie][a6] 的 ZIP 包就可以用 [脚注 1]。解压缩或提取下载的文件然后把它拷贝到 SD 卡里。使用 [Pi Filler][a7] 可以让这些过程变得更简单。[下载 Pi Filer 1.3][8] 或最新的版本。解压或提取下载文件之后打开它,你应该会看到这样的提示:
|
||||
|
||||
![Pi Filler prompt](https://opensource.com/sites/default/files/2-image_by_mitchell_mclaughlin_cc_by-sa_4.0.png "Pi Filler prompt")
|
||||
|
||||
确保 USB 读卡器这时还没有插上。如果已经插上了那就先推出。点 Continue 继续下一步。你会看到一个让你选择文件的界面,选择你之前解压缩后的树莓派系统文件。然后你会看到另一个提示,如图所示:
|
||||
确保 USB 读卡器这时还没有插上。如果已经插上了那就先弹出。点 “Continue” 继续下一步。你会看到一个让你选择文件的界面,选择你之前解压缩后的树莓派系统文件。然后你会看到另一个提示,如图所示:
|
||||
|
||||
![USB card reader prompt](https://opensource.com/sites/default/files/3-image_by_mitchell_mclaughlin_cc_by-sa_4.0.png "USB card reader")
|
||||
|
||||
把 MicroSD 卡 (推荐 32 GB ,至少 16GB) 插入到 USB MicroSD 卡读卡器里。然后把 USB 读卡器接入到你的电脑里。你可以把你的 SD 卡重命名为 “Raspberry” 以区别其他设备。然后点击 continue。请先确保你的 SD 卡是空的,因为 Pi Filler 会在运行时 _擦除_ 所有事先存在 SD 卡里的内容。如果你要备份卡里的内容,那你最好就马上备份。当你点 continue 的时候,Raspbian OS 就会被写入到 SD 卡里。这个过程大概会花费一到三分钟左右。当写入完成后,推出 USB 读卡器,把 SD 卡拔出来插入到树莓派的 SD 卡槽里。把电源线接上,给树莓派提供电源。这时树莓派就会自己启动。树莓派的默认登录账户信息是:
|
||||
把 MicroSD 卡(推荐 32 GB ,至少 16GB)插入到 USB MicroSD 卡读卡器里。然后把 USB 读卡器接入到你的电脑里。你可以把你的 SD 卡重命名为 “Raspberry” 以区别其他设备。然后点击 “Continue”。请先确保你的 SD 卡是空的,因为 Pi Filler 会在运行时 _擦除_ 所有事先存在 SD 卡里的内容。如果你要备份卡里的内容,那你最好就马上备份。当你点 “Continue” 的时候,Raspbian OS 就会被写入到 SD 卡里。这个过程大概会花费一到三分钟左右。当写入完成后,推出 USB 读卡器,把 SD 卡拔出来插入到树莓派的 SD 卡槽里。把电源线接上,给树莓派供电。这时树莓派就会自己启动。树莓派的默认登录账户信息是:
|
||||
|
||||
**用户名: pi
|
||||
密码: raspberry**
|
||||
- 用户名: pi
|
||||
- 密码:raspberry
|
||||
|
||||
当树莓派首次启动完成时,会跳出一个标题为 <ruby>设置选项<rt>Setup Options</rt></ruby> 的配置界面,就像下面的图片一样 [2]:
|
||||
当树莓派首次启动完成时,会跳出一个标题为 “<ruby>设置选项<rt>Setup Options</rt></ruby>” 的配置界面,就像下面的图片一样 [脚注 2]:
|
||||
|
||||
![Raspberry Pi software configuration setup](https://opensource.com/sites/default/files/4-image_by_mitchell_mclaughlin_cc_by-sa_4.0.png "Raspberry Pi software configuration setup")
|
||||
|
||||
选择 “Expand Filesystem” 这一选项并回车 [3]。 同时,我还推荐选择第二个选项 “Change User Password”。这对保证安全性来说尤为重要。它还能个性化你的树莓派。
|
||||
选择 “<ruby>扩展文件系统<rt>Expand Filesystem</rt></ruby>” 这一选项并回车 [脚注 3]。 同时,我还推荐选择第二个选项 “<ruby>修改密码<rt>Change User Password</rt></ruby>”。这对保证安全性来说尤为重要。它还能个性化你的树莓派。
|
||||
|
||||
在选项列表中选择第三项 “Enable Boot To Desktop/Scratch” 并回车。这时会跳到另一个标题为 “Choose boot option” 的界面,就像下面这张图这样。
|
||||
在选项列表中选择第三项 “<ruby>启用引导到桌面<rt>Enable Boot To Desktop/Scratch</rt></ruby>” 并回车。这时会跳到另一个标题为 “<ruby>选择引导选项<rt>Choose boot option</rt></ruby>” 的界面,就像下面这张图这样:
|
||||
|
||||
![Choose boot option](https://opensource.com/sites/default/files/5-image_by_mitchell_mclaughlin_cc_by-sa_4.0.png "Choose boot option")
|
||||
|
||||
在 “Choose boot option” 这个界面选择第二个选项 “Desktop log in as user 'pi' at the graphical desktop” 并回车 [4]。完成这个操作之后会回到之前的 “Setup Options” 界面。如果没有回到之前的界面的话就选择当前界面底部的 “OK” 按钮并回车。
|
||||
在这个界面选择第二个选项 “<ruby>以用户‘pi’登录图形化桌面<rt>Desktop log in as user 'pi' at the graphical desktop</rt></ruby>” 并回车 [脚注 4]。完成这个操作之后会回到之前的 “<ruby>设置选项<rt>Setup Options</rt></ruby>” 界面。如果没有回到之前的界面的话就选择当前界面底部的 “OK” 按钮并回车。
|
||||
|
||||
当这些操作都完成之后,选择当前界面底部的 “Finish” 按钮并回车,这时它就会自动重启。如果没有自动重启的话,就在终端里使用如下命令来重启。
|
||||
|
||||
**$ sudo reboot**
|
||||
```
|
||||
$ sudo reboot
|
||||
```
|
||||
|
||||
接上一步的重启,如果所有步骤都顺利进行的话,你会进入到类似下面这样桌面环境中。
|
||||
|
||||
@ -76,17 +78,14 @@
|
||||
|
||||
```
|
||||
$ sudo apt-get update
|
||||
|
||||
$ sudo apt-get upgrade-y
|
||||
|
||||
$ sudo apt-get dist-upgrade -y
|
||||
|
||||
$ sudo rpi-update
|
||||
```
|
||||
|
||||
这些操作可能会花费几分钟时间。完成之后,现在运行着的树莓派就是最新的了。
|
||||
|
||||
### 步骤 2: 配置树莓派
|
||||
### 步骤 2: 配置树莓派
|
||||
|
||||
SSH 指的是 Secure Shell,是一种加密网络协议,可让你在计算机和树莓派之间安全地传输数据。 你可以从 Mac 的命令行控制你的树莓派,而无需显示器或键盘。
|
||||
|
||||
@ -96,9 +95,9 @@ SSH 指的是 Secure Shell,是一种加密网络协议,可让你在计算机
|
||||
$ sudo ifconfig
|
||||
```
|
||||
|
||||
如果你在使用以太网,看 “eth0” 部分。如果你在使用 Wi-Fi, 看 “wlan0” 部分。
|
||||
如果你在使用以太网,看 `eth0` 部分。如果你在使用 Wi-Fi, 看 `wlan0` 部分。
|
||||
|
||||
查找 “inet addr”,后跟一个 IP 地址,如 192.168.1.115,这是本篇文章中使用的默认 IP。
|
||||
查找 `inet addr`,后跟一个 IP 地址,如 192.168.1.115,这是本篇文章中使用的默认 IP。
|
||||
|
||||
有了这个地址,在终端中输入 :
|
||||
|
||||
@ -106,9 +105,9 @@ $ sudo ifconfig
|
||||
$ ssh pi@192.168.1.115
|
||||
```
|
||||
|
||||
对于 PC 上的 SSH,请参见脚注 [5]。
|
||||
对于 PC 上的 SSH,请参见 [脚注 5]。
|
||||
|
||||
出现提示时输入默认密码 “raspberry”,除非你之前更改过密码。
|
||||
出现提示时输入默认密码 `raspberry`,除非你之前更改过密码。
|
||||
|
||||
现在你已经通过 SSH 登录成功。
|
||||
|
||||
@ -120,22 +119,18 @@ $ ssh pi@192.168.1.115
|
||||
$ sudo apt-get install xrdp
|
||||
```
|
||||
|
||||
Xrdp 支持 Mac 和 PC 的 Microsoft Remote Desktop 客户端。
|
||||
xrdp 支持 Mac 和 PC 的 Microsoft Remote Desktop 客户端。
|
||||
|
||||
在 Mac 上,在 App store 中搜索 “Microsoft Remote Desktop”。 下载它。 (对于 PC,请参见脚注 [6]。)
|
||||
在 Mac 上,在 App store 中搜索 “Microsoft Remote Desktop”。 下载它。 (对于 PC,请参见 [脚注 6]。)
|
||||
|
||||
安装完成之后,在你的 Mac 中搜索一个叫 “Microsoft Remote Desktop” 的应用并打开它,你会看到 :
|
||||
|
||||
![Microsoft Remote Desktop](https://opensource.com/sites/default/files/7-image_by_mitchell_mclaughlin_cc_by-sa_4.0.png "Microsoft Remote Desktop")
|
||||
|
||||
*图片来自 Mitchell McLaughlin, CC BY-SA 4.0*
|
||||
|
||||
点击 “New” 新建一个远程连接,在空白处填写如下配置。
|
||||
|
||||
![Setting up a remote connection](https://opensource.com/sites/default/files/8-image_by_mitchell_mclaughlin_cc_by-sa_4.0.png "Setting up a remote connection")
|
||||
|
||||
*图片来自 Mitchell McLaughlin, CC BY-SA 4.0*
|
||||
|
||||
关闭 “New” 窗口就会自动保存。
|
||||
|
||||
你现在应该看到 “My Desktop” 下列出的远程连接。 双击它。
|
||||
@ -146,7 +141,7 @@ Xrdp 支持 Mac 和 PC 的 Microsoft Remote Desktop 客户端。
|
||||
|
||||
好了,现在你不需要额外的鼠标、键盘或显示器就能控制你的树莓派。这是一个更为轻量级的配置。
|
||||
|
||||
### 静态本地 IP 地址
|
||||
### 静态化本地 IP 地址
|
||||
|
||||
有时候你的本地 IP 地址 192.168.1.115 会发生改变。我们需要让这个 IP 地址静态化。输入:
|
||||
|
||||
@ -154,17 +149,17 @@ Xrdp 支持 Mac 和 PC 的 Microsoft Remote Desktop 客户端。
|
||||
$ sudo ifconfig
|
||||
```
|
||||
|
||||
从 “eth0” 部分或 “wlan0” 部分,“inet addr”(树莓派当前 IP),“bcast”(广播 IP 范围)和 “mask”(子网掩码地址))中写入。 然后输入:
|
||||
从 `eth0` 部分或 `wlan0` 部分,记下 `inet addr`(树莓派当前 IP),`bcast`(广播 IP 范围)和 `mask`(子网掩码地址)。 然后输入:
|
||||
|
||||
```
|
||||
$ netstat -nr
|
||||
```
|
||||
|
||||
记下 “destination” 和 “gateway/network”。
|
||||
记下 `destination` 和 `gateway/network`。
|
||||
|
||||
![Setting up a local IP address](https://opensource.com/sites/default/files/setting_up_local_ip_address.png "Setting up a local IP address")
|
||||
|
||||
应该大概是这样子的:
|
||||
大概应该是这样子的:
|
||||
|
||||
```
|
||||
net address 192.168.1.115
|
||||
@ -181,7 +176,7 @@ destination 192.168.1.0
|
||||
$ sudo nano /etc/dhcpcd.conf
|
||||
```
|
||||
|
||||
不要使用 **/etc/network/interfaces**。
|
||||
不要去动 `/etc/network/interfaces`。
|
||||
|
||||
剩下要做的就是把这些内容追加到这个文件的底部,把 IP 换成你想要的 IP 地址。
|
||||
|
||||
@ -206,25 +201,25 @@ $ sudo ifconfig
|
||||
|
||||
这时你就可以看到你的树莓派上的新的静态配置了。
|
||||
|
||||
### 静态全局 IP address
|
||||
### 静态化全局 IP 地址
|
||||
|
||||
如果您的 ISP(互联网服务提供商)已经给您一个静态外部 IP 地址,您可以跳到端口转发部分。 如果没有,请继续阅读。
|
||||
|
||||
你已经设置了 SSH,远程桌面和静态内部 IP 地址,因此现在本地网络中的计算机将会知道在哪里可以找到你的树莓派。 但是你仍然无法从本地 Wi-Fi 网络外部访问你的树莓派。 你需要树莓派可以从互联网上的任何地方公开访问。这需要静态外部 IP 地址 [7]。
|
||||
你已经设置了 SSH、远程桌面和静态内部 IP 地址,因此现在本地网络中的计算机将会知道在哪里可以找到你的树莓派。 但是你仍然无法在本地 Wi-Fi 网络外部访问你的树莓派。 你需要树莓派可以从互联网上的任何地方公开访问。这需要静态的外部 IP 地址 [脚注 7]。
|
||||
|
||||
调用您的 ISP 并请求静态外部(有时称为静态全局)IP 地址可能会是一个非常敏感的过程。 ISP 拥有决策权,所以我会非常小心处理。 他们可能拒绝你的的静态外部 IP 地址请求。 如果他们拒绝了你的请求,你不要怪罪于他们,因为这种类型的请求有法律和操作风险。 他们特别不希望客户运行中型或大型互联网服务。 他们可能会明确地询问为什么需要一个静态的外部 IP 地址。 最好说实话,告诉他们你打算主办一个低流量的个人网站或类似的小型非营利互联网服务。 如果一切顺利,他们应该会建立一个任务,并在一两个星期内给你打电话。
|
||||
联系您的 ISP 并请求静态的外部(有时称为静态全局)IP 地址可能会是一个非常敏感的过程。 ISP 拥有决策权,所以我会非常小心处理。 他们可能拒绝你的的静态外部 IP 地址请求。 如果他们拒绝了你的请求,你不要怪罪于他们,因为这种类型的请求有法律和操作风险。 他们特别不希望客户运行中型或大型互联网服务。 他们可能会明确地询问为什么需要一个静态的外部 IP 地址。 最好说实话,告诉他们你打算主办一个低流量的个人网站或类似的小型非营利互联网服务。 如果一切顺利,他们应该会建立一个工单,并在一两个星期内给你打电话。
|
||||
|
||||
### 端口转发
|
||||
|
||||
这个新获得的 ISP 分配的静态全局 IP 地址是用于访问路由器。 树莓派现在仍然无法访问。 你需要设置端口转发才能访问树莓派。
|
||||
|
||||
端口是信息在互联网上传播的虚拟途径。 你有时需要转发端口,以使计算机像树莓派一样可以访问 Internet,因为它位于网络路由器后面。 VollmilchTV 专栏在 YouTube 上的一个视频,名字是[什么是 TCP/IP,端口,路由,Intranet,防火墙,互联网][9],帮助我更好地了解端口。
|
||||
端口是信息在互联网上传播的虚拟途径。 你有时需要转发端口,以使计算机像树莓派一样可以访问 Internet,因为它位于网络路由器后面。 VollmilchTV 专栏在 YouTube 上的一个视频,名字是[什么是 TCP/IP,端口,路由,Intranet,防火墙,互联网][9],可以帮助你更好地了解端口。
|
||||
|
||||
端口转发可用于像 树莓派 Web 服务器或 VoIP 或点对点下载的应用程序。 有 [65,000+个端口][10]可供选择,因此你可以为你构建的每个 Internet 应用程序分配一个不同的端口。
|
||||
端口转发可用于像 树莓派 Web 服务器或 VoIP 或点对点下载的应用程序。 有 [65000个以上的端口][10]可供选择,因此你可以为你构建的每个 Internet 应用程序分配一个不同的端口。
|
||||
|
||||
设置端口转发的方式取决于你的路由器。 如果你有 Linksys 的话,Gabriel Ramirez 在 YouTbue 上有一个标题叫 [How to go online with your Apache Ubuntu server][a2] 的视频解释了如何设置。 如果您没有 Linksys,请阅读路由器附带的文档,以便自定义和定义要转发的端口。
|
||||
设置端口转发的方式取决于你的路由器。 如果你有 Linksys 的话,Gabriel Ramirez 在 YouTbue 上有一个标题叫 [如何让你的 Apache Ubuntu 服务器连到互联网][a2] 的视频解释了如何设置。 如果您没有 Linksys,请阅读路由器附带的文档,以便自定义和定义要转发的端口。
|
||||
|
||||
你将需要转发 SSH 以及远程桌面端口。
|
||||
你需要转发 SSH 以及远程桌面端口。
|
||||
|
||||
如果你认为你已经过配置端口转发了,输入下面的命令以查看它是否正在通过 SSH 工作:
|
||||
|
||||
@ -234,17 +229,17 @@ $ ssh pi@your_global_ip_address
|
||||
|
||||
它应该会提示你输入密码。
|
||||
|
||||
检查端口转发是否也适用于远程桌面。 打开 Microsoft Remote Desktop。 你之前的的远程连接设置应该已经保存了,但需要使用静态外部 IP 地址(例如195.198.227.116)来更新 “PC名称” 字段,而不是静态内部地址(例如 192.168.1.115)。
|
||||
检查端口转发是否也适用于远程桌面。 打开 Microsoft Remote Desktop。 你之前的的远程连接设置应该已经保存了,但需要使用静态的外部 IP 地址(例如 195.198.227.116)来更新 “PC 名称” 字段,而不是静态的内部地址(例如 192.168.1.115)。
|
||||
|
||||
现在,尝试通过远程桌面连接。 它应该简单地加载并到达树莓派的桌面。
|
||||
现在,尝试通过远程桌面连接。 它应该简单地加载并显示树莓派的桌面。
|
||||
|
||||
![Raspberry Pi desktop](https://opensource.com/sites/default/files/6-image_by_mitchell_mclaughlin_cc_by-sa_4.0_1.png "Raspberry Pi desktop")
|
||||
|
||||
好了, 树莓派现在可以从互联网上访问了,并且已经准备好进行高级项目了。
|
||||
|
||||
作为一个奖励选项,您可以保持两个远程连接到您的 Pi。 一个通过互联网,另一个通过 LAN(局域网)。很容易设置。在 Microsoft Remote Desktop 中,保留一个称为 “Pi Internet” 的远程连接,另一个称为 “Pi Local”。 将 Pi Internet 的 “PC name” 配置为静态外部 IP 地址,例如 195.198.227.116。 将 Pi Local 的 “PC name” 配置为静态内部 IP 地址,例如192.168.1.115。 现在,您可以选择在全球或本地连接。
|
||||
作为一个奖励选项,您可以保持到您的 Pi 的两个远程连接。 一个通过互联网,另一个通过 LAN(局域网)。很容易设置。在 Microsoft Remote Desktop 中,保留一个称为 “Pi Internet” 的远程连接,另一个称为 “Pi Local”。 将 Pi Internet 的 “PC 名称” 配置为静态外部 IP 地址,例如 195.198.227.116。 将 Pi Local 的 “PC 名称” 配置为静态内部 IP 地址,例如 192.168.1.115。 现在,您可以选择在全局或本地连接。
|
||||
|
||||
如果你还没有看过由 Gabriel Ramirez 发布的 [如何使用您的Apache Ubuntu服务器上线][a3],那么你可以去看一下,作为过渡到第二个项目的教程。 它将向您展示项目背后的技术架构。 在我们的例子中,你使用的是树莓派而不是 Ubuntu 服务器。 动态 DNS 位于域公司和您的路由器之间,这是 Ramirez 省略的部分。 除了这个微妙之处外,视频是在整体上解释系统的工作原理。 您可能会注意到本教程涵盖了树莓派设置和端口转发,这是服务器端或后端。 查看原始来源,涵盖域名,动态 DNS,Jekyll(静态 HTML 生成器)和 Apache(网络托管)的更高级项目,这是客户端或前端。
|
||||
如果你还没有看过由 Gabriel Ramirez 发布的 [如何让你的 Apache Ubuntu 服务器连到互联网][a3],那么你可以去看一下,作为过渡到第二个项目的教程。 它将向您展示项目背后的技术架构。 在我们的例子中,你使用的是树莓派而不是 Ubuntu 服务器。 动态 DNS 位于域名公司和您的路由器之间,这是 Ramirez 省略的部分。 除了这个微妙之处外,视频是在整体上解释系统的工作原理。 您可能会注意到本教程涵盖了树莓派设置和端口转发,这是服务器端或后端。 查看原始来源,涵盖域名,动态 DNS,Jekyll(静态 HTML 生成器)和 Apache(网络托管)的更高级项目,这是客户端或前端。
|
||||
|
||||
### 脚注
|
||||
|
||||
@ -264,7 +259,7 @@ $ sudo-rasps-config
|
||||
|
||||
![PuTTY configuration](https://opensource.com/sites/default/files/putty_configuration.png "PuTTY configuration")
|
||||
|
||||
[下载并运行 PuTTY][11] 或 Windows 的另一个 SSH 客户端。 在该字段中输入你的 IP 地址,如上图所示。 将默认端口保留在 22。 回车,PuTTY 将打开一个终端窗口,提示你输入用户名和密码。 填写然后开始在树莓派上进行你的远程工作。
|
||||
[下载并运行 PuTTY][11] 或 Windows 的其它 SSH 客户端。 在该字段中输入你的 IP 地址,如上图所示。 将默认端口保留为 22。 回车,PuTTY 将打开一个终端窗口,提示你输入用户名和密码。 填写然后开始在树莓派上进行你的远程工作。
|
||||
|
||||
[6] 如果尚未安装,请下载 [Microsoft Remote Desktop][12]。 搜索您的计算机上的的 Microsoft Remote Desktop。 运行。 提示时输入 IP 地址。 接下来,会弹出一个 xrdp 窗口,提示你输入用户名和密码。
|
||||
|
||||
@ -276,12 +271,10 @@ $ sudo-rasps-config
|
||||
|
||||
作者简介:
|
||||
|
||||
Mitchell McLaughlin - 我是一名开放网络的贡献者和开发者。我感兴趣的领域很广泛,但我特别喜欢开源软件/硬件,比特币和编程。 我住在旧金山 我有过一些简短的 GoPro 和 Oracle 工作经验。
|
||||
|
||||
Mitchell McLaughlin - 我是一名开放网络的贡献者和开发者。我感兴趣的领域很广泛,但我特别喜欢开源软件/硬件,比特币和编程。 我住在旧金山,我有过一些简短的 GoPro 和 Oracle 工作经验。
|
||||
|
||||
-------------
|
||||
|
||||
|
||||
via: https://opensource.com/article/17/3/building-personal-web-server-raspberry-pi-3
|
||||
|
||||
作者:[Mitchell McLaughlin ][a]
|
@ -0,0 +1,68 @@
|
||||
买个 DDoS 服务干掉你的对手
|
||||
========================
|
||||
|
||||
> 随着物联网设备的普及,网络犯罪分子通过利用密码的缺陷而提供拒绝服务攻击。
|
||||
|
||||
![](http://images.techhive.com/images/article/2016/12/7606416730_e659cea89c_o-100698667-large.jpg)
|
||||
|
||||
随着物联网设备飞速发展,分布式拒绝服务(DDoS)攻击正在成为一种危险的趋势。就如 [DNS 服务商 Dyn 上年秋季之遭遇][3] 一样,黑客似乎瞄上了每个人,使用未保护的物联网设备来轰炸网络的做法正在抬头。
|
||||
|
||||
可雇佣的 DDoS 攻击的出现意味着即使是最不精通技术的人都能精准报复某些网站。就像在柜台前面买个东西一样方便,然后就可以彻底搞定一个公司。
|
||||
|
||||
根据 [Neustar][4] 的报告,四分之三的国际品牌、机构和公司都是 DDoS 攻击的受害者。[每天至少会发生 3700 起 DDoS 攻击][5]。
|
||||
|
||||
睿科网络公司(A10 Networks)网络运营总监 Chase Cunningham 说:“想要找个可用的物联网设备,你只需要在地下网站四处打听一下 Mirai 扫描器代码,一旦你找到了,你将能够利用在线的每一台设备来进行攻击”。
|
||||
|
||||
“或者你可以去一些类似 Shodan 的网站,然后简单的搜一下设备特定的请求。当你得到这些信息之后,你就可以将你所雇佣的 DDoS 工具配置正确的流量模拟器类型、指向正确的目标并发动攻击。”
|
||||
|
||||
“几乎所有东西都是可买卖的。”他补充道,“你可以购买一个 ‘stresser’,这就是个随便哪个会点按钮的人都会使用的 DDoS 僵尸网络。”
|
||||
|
||||
网络安全提供商 Imperva 说,用户只需要出几十美金,就可以快速发动攻击。有些公司在它们的网站上说它们的工具包含肉鸡负载和 CnC(命令与控制)文件。使用这些工具,那些有点想法的肉鸡大师(或者被称为 herders)就可以开始传播恶意软件,通过垃圾邮件、漏洞扫描程序、暴力攻击等来感染设备。
|
||||
|
||||
大部分 [stresser 和 booter][6] 都会有一个常见的、基于订阅服务的 SaaS(软件即服务)业务模式。来自 Incapsula 公司的 [Q2 2015 DDoS 报告][7] 显示,在 DDoS 上的月均每小时花费是 38 美元(规模较低的是 19.99 美元)。
|
||||
|
||||
![雇佣ddos服务](http://images.techhive.com/images/article/2017/03/ddos-hire-100713247-large.jpg)
|
||||
|
||||
“stresser 和 booter 只是新世界的一个副产品,这些可以扳倒企业和机构的服务只能运作在灰色领域”,Imperva 写道。
|
||||
|
||||
虽然成本不同,但是企业受到的[各种攻击,每次损失在 1.4 万美元到 235 万美元之间][8]。而且企业受到一次攻击后,[有 82% 的可能性会再次受到攻击][9]。
|
||||
|
||||
物联网洪水攻击(DoT,DDoS of Things)使用物联网设备建立的僵尸网络可造成非常大规模的 DDoS 攻击。物联网洪水攻击会利用成百上千的物联网设备攻击,无论是大型服务提供商还是企业,均无幸免。
|
||||
|
||||
“大部分讲究声誉的 DDoS 卖家都会将他们的工具配置为可修改的,这样你就可以轻松地设置攻击的类型。虽然我还没怎么看到有哪些可以‘付费的’物联网流量模拟器的选项,但我敢肯定就要有了。如果是我来搞这个服务,我是绝对会加入这个选项的。”Cunningham 如是说。
|
||||
|
||||
由 IDG 新闻服务的消息可知,要建造一个 DDoS 服务也是很简单的。通常黑客会租用 6 到 12 个左右的服务器,然后使用它们随意的攻击任何目标。去年十月下旬,HackForums.net [关闭][10]了他们的“服务器压力测试”版块,这个做法就是考虑到黑客可能通过使用他们每月十美元的服务建造可雇佣的 DDoS 服务。
|
||||
|
||||
同样地在十二月时,美国和欧洲的执法机构 [逮捕][11] 34个参与可雇佣的 DDoS 服务的嫌犯。
|
||||
|
||||
但是如果这很简单,怎么还没有经常发生攻击?
|
||||
|
||||
Cunningham 说这其实每时每刻都在发生,实际上每天每秒都在发生。他说:”你不知道它们的原因是因为大部分都是扰乱攻击,而不是大规模的、想要搞倒公司的攻击。“
|
||||
|
||||
他说,大部分的攻击平台只出售那些会让系统宕机一个小时或稍长一点的攻击。通常宕机一小时的攻击大概需要花费 15 到 50 美元。当然这得看平台,有些可能一小时就要花上百美元。
|
||||
|
||||
**减少这些攻击的解决方案是让用户把所有联网设备的出厂预置的密码改掉,然后还要禁用那些你不需要的功能。**
|
||||
|
||||
(题图:[Victor](https://www.flickr.com/photos/v1ctor/7606416730/))
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.csoonline.com/article/3180246/data-protection/hire-a-ddos-service-to-take-down-your-enemies.html
|
||||
|
||||
作者:[Ryan Francis][a]
|
||||
译者:[kenxx](https://github.com/kenxx)
|
||||
校对:[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.csoonline.com/author/Ryan-Francis/
|
||||
[1]:http://csoonline.com/article/3103122/security/how-can-you-detect-a-fake-ransom-letter.html#tk.cso-infsb
|
||||
[2]:https://www.incapsula.com/ddos/ddos-attacks/denial-of-service.html
|
||||
[3]:http://csoonline.com/article/3135986/security/ddos-attack-against-overwhelmed-despite-mitigation-efforts.html
|
||||
[4]:https://ns-cdn.neustar.biz/creative_services/biz/neustar/www/resources/whitepapers/it-security/ddos/2016-apr-ddos-report.pdf
|
||||
[5]:https://www.a10networks.com/resources/ddos-trends-report
|
||||
[6]:https://www.incapsula.com/ddos/booters-stressers-ddosers.html
|
||||
[7]:https://www.incapsula.com/blog/ddos-global-threat-landscape-report-q2-2015.html
|
||||
[8]:http://www.datacenterknowledge.com/archives/2016/05/13/number-of-costly-dos-related-data-center-outages-rising/
|
||||
[9]:http://www.networkworld.com/article/3064677/security/hit-by-ddos-you-will-likely-be-struck-again.html
|
||||
[10]:http://www.pcworld.com/article/3136730/hacking/hacking-forum-cuts-section-allegedly-linked-to-ddos-attacks.html
|
||||
[11]:http://www.pcworld.com/article/3149543/security/dozens-arrested-in-international-ddos-for-hire-crackdown.html
|
@ -1,6 +1,6 @@
|
||||
ucasFL translating
|
||||
How to make file-specific setting changes in Vim using Modeline
|
||||
============================================================
|
||||
ch-cn translating
|
||||
|
||||
### On this page
|
||||
|
||||
|
@ -1,3 +1,5 @@
|
||||
tranlated by mudongliang
|
||||
|
||||
FEWER MALLOCS IN CURL
|
||||
===========================================================
|
||||
|
||||
|
@ -1,74 +0,0 @@
|
||||
雇个 `DDoS` 服务干掉你的对手
|
||||
========================
|
||||
|
||||
>随着物联网设备的普及,网络犯罪分子提供拒绝服务攻击来占密码问题的便宜。
|
||||
|
||||
![](http://images.techhive.com/images/article/2016/12/7606416730_e659cea89c_o-100698667-large.jpg)
|
||||
|
||||
随物联网设备飞速发展,分布式拒绝服务攻击也变得越来越具有危险性了。就如 [DNS 服务商 Dyn 上年秋季之遭遇][3] 一样,黑客似乎瞄上了每个人,使用未受保护的物联网设备来轰炸网络正迎面而来。
|
||||
|
||||
可雇用的分布式拒绝服务攻击的出现意味着每个会点技术的人都能精准报复一些网站。加大攻击能力甚至可以从系统级别的让一个公司完蛋。
|
||||
|
||||
根据 [Neustar][4] 的报告,全球四分之三的品牌、组织和公司都是 `DDos` 攻击的受害者。[每天 `DDoS` 攻击发生次数][5] 不少于 3700 次。
|
||||
|
||||
|
||||
#### [■ 相关阅读:如何判断假绑架信?][1]
|
||||
|
||||
睿科网络公司(A10 Networks)网络运营总监 Chase Cunningham 说:“想要找个可用的物联网设备,你只需要在地下网站找一个 `Mirai` 扫描器,一旦你得到了这款扫描器,你将能够利用在线的每一台设备来进行攻击”。
|
||||
|
||||
“或者你可以去一些类似 `Shodan` 的网站,然后简单的搜一下特殊设备的请求。当你得到这些信息之后,你就可以将你的雇佣的 `DDoS` 工具配置正确的流量模拟器类型、指向正确的目标并发动攻击。”
|
||||
|
||||
“几乎所有东西都是可售的。”他补充道,“你可以购买一个‘stresser’,这就是个随便哪个会点按钮的人都会使用的 `DDoS` 功能的僵尸网络。”
|
||||
|
||||
>当你得到这些信息之后,你就可以将你的雇佣的 `DDoS` 工具配置正确的流量模拟器类型、指向正确的目标并发动攻击。
|
||||
|
||||
>Chase Cunningham,睿科网络公司(A10 Networks)网络运营总监
|
||||
|
||||
网络安全提供商 Imperva 说,用户只需要出几十元美金,就可以快速发动攻击。有些公司编写了一些工具包含了肉鸡负载和 `CnC`(命令与控制)文件。使用这些工具,那些有点想法的肉鸡大师(或者说 `herders`)就可以开始通过垃圾邮件来传播使设备感染恶意软件、漏洞扫描程序、暴力攻击等等。
|
||||
|
||||
大部分 [stressers and booters][6] 都会有一个常见的、基于订阅的 `SaaS`(软件即服务)业务模式。来自 Incapsula 公司的 [Q2 2015 DDoS 报告][7] 显示,一个月范围内平均每小时就会有38美元(规模较低的在19.99美元)花在购买 `DDoS` 服务上。
|
||||
|
||||
![雇佣ddos服务](http://images.techhive.com/images/article/2017/03/ddos-hire-100713247-large.jpg)
|
||||
|
||||
“`Stresser` 和 `booter` 只是一个新型现实的副产品,这些可以扳倒企业和组织的服务只被允许运作在灰色领域”,Imperva 写道。
|
||||
|
||||
虽然成本不同,但是企业受到 [攻击可在任何地方,每次损失在 1.4 万美元到 235 万美元][8]。然而企业受到一次攻击后,[有 82% 的可能性会再次受到攻击][9]。
|
||||
|
||||
物联网洪水攻击(DoT, DDoS of Things)使用物联网设备建立僵尸网络可造成非常大规模的 `DDoS` 攻击。物联网洪水攻击会利用成百上千的物联网设备造成杠杆来攻击大型服务提供商。
|
||||
|
||||
“大部分可信的 `DDoS` 卖家都会将他们的工具的配置设置的很简单,这样你就可以简单的更换配置开始攻击。虽然我还没怎么看到有哪些可以‘付费’物联网流量模拟器的选项,但我敢肯定准备要有了。如果是我来搞这个服务,我是绝对会加入这个选项的。”Cunningham 如是说。
|
||||
|
||||
由 IDG 新闻服务的故事我们可知,要建造一个攻击服务的 `DDoS` 服务也可以很简单。通常黑客会租用 6 到 12 个左右的服务器,然后使用他们随意的攻击任何目标。十月下旬,HackForums.net [关闭][10]了他们的”服务器压力测试“部分,此次做法就是考虑到黑客可能通过使用他们十美元每月的服务建造可雇佣的 `DDoS` 服务。
|
||||
|
||||
同样地在十二月时,美国和欧洲的执法机构 [逮捕][11] 34个参与可雇佣的 `DDoS` 服务的嫌犯。
|
||||
|
||||
如果这很简单,怎么还没有经常发生攻击?
|
||||
|
||||
Cunningham 说这其实每时每刻都在发生,实际上每天每秒没完没了。他说:”你不知道的原因是因为大部分的都是扰乱攻击,而不是大规模的、想要搞倒公司的攻击。“
|
||||
|
||||
他说,大部分的攻击平台只出售那些会让系统宕机一个小时或就长一点点的攻击。通常宕机一小时的攻击大概需要15到50美元的成本。当然这得看平台,有些可能想让其一小时就要花上百美元。
|
||||
|
||||
减少这些攻击的解决方案是让用户把所有联网设备的恢复出厂设置的预设密码改掉,改掉默认密码然后还要禁用那些你不需要的功能。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.csoonline.com/article/3180246/data-protection/hire-a-ddos-service-to-take-down-your-enemies.html
|
||||
|
||||
作者:[Ryan Francis][a]
|
||||
译者:[kenxx](https://github.com/kenxx)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.csoonline.com/author/Ryan-Francis/
|
||||
[1]:http://csoonline.com/article/3103122/security/how-can-you-detect-a-fake-ransom-letter.html#tk.cso-infsb
|
||||
[2]:https://www.incapsula.com/ddos/ddos-attacks/denial-of-service.html
|
||||
[3]:http://csoonline.com/article/3135986/security/ddos-attack-against-overwhelmed-despite-mitigation-efforts.html
|
||||
[4]:https://ns-cdn.neustar.biz/creative_services/biz/neustar/www/resources/whitepapers/it-security/ddos/2016-apr-ddos-report.pdf
|
||||
[5]:https://www.a10networks.com/resources/ddos-trends-report
|
||||
[6]:https://www.incapsula.com/ddos/booters-stressers-ddosers.html
|
||||
[7]:https://www.incapsula.com/blog/ddos-global-threat-landscape-report-q2-2015.html
|
||||
[8]:http://www.datacenterknowledge.com/archives/2016/05/13/number-of-costly-dos-related-data-center-outages-rising/
|
||||
[9]:http://www.networkworld.com/article/3064677/security/hit-by-ddos-you-will-likely-be-struck-again.html
|
||||
[10]:http://www.pcworld.com/article/3136730/hacking/hacking-forum-cuts-section-allegedly-linked-to-ddos-attacks.html
|
||||
[11]:http://www.pcworld.com/article/3149543/security/dozens-arrested-in-international-ddos-for-hire-crackdown.html
|
@ -1,465 +0,0 @@
|
||||
GitLab 工作流概览
|
||||
======
|
||||
|
||||
GitLab 是一个基于 git 的仓库管理程序,也是一个方便软件开发的强大完整应用。
|
||||
|
||||
GitLab 拥有一个“用户新人友好”的界面,通过图形界面和命令行界面,使你的工作更加具有效率。GitLab 不仅仅对开发者是一个有用的工具,它甚至可以被集成到你的整个团队中,使得每一个人获得一个独自唯一的平台。
|
||||
|
||||
GitLab 工作流逻辑符合使用者思维,使得整个平台变得更加易用。相信我,使用一次,你就离不开它了!
|
||||
|
||||
### GitLab 工作流
|
||||
|
||||
**GitLab 工作流** 使用 GitLab 作为平台管理你的代码,它是一系列具有逻辑可能性的过程——这个逻辑过程依据软件开发的生命周期来制定。
|
||||
|
||||
GitLab 工作流遵循了 [GitLab Flow][97] 策略,这是由一系列由**基于 Git** 的方法和策略组成的,这些方法为版本的管理,例如**分支策略**,**Git最佳实践**等等提供了保障。
|
||||
|
||||
通过 GitLab 工作流,可以很方便的[提升](https://about.gitlab.com/2016/09/13/gitlab-master-plan/)团队的工作效率以及凝聚力。这种提升,从引入一个新的项目开始,一直到发布这个项目,成为一个产品都有所体现。这就是我们所说的“如何通过最快的速度把一个点子在 10 步之内变成一个产品”。
|
||||
|
||||
![FROM IDEA TO PRODUCTION IN 10 STEPS](https://about.gitlab.com/images/blogimages/idea-to-production-10-steps.png)
|
||||
|
||||
#### 软件开发阶段
|
||||
|
||||
一般情况下,软件开发经过 10 个主要阶段;GitLab 为这 10 个阶段依次提供了解决方案:
|
||||
|
||||
1. **IDEA**: 每一个从点子开始的项目,通常来源于一次闲聊。在这个阶段,GitLab 集成了 [Mattermost][44]。
|
||||
2. **ISSUE**: 最有效的讨论一个点子的方法,就是为这个点子建立一个工单讨论。你的团队和你的合作伙伴可以帮助你去提升这个点子,通过 [issue tracker][43]
|
||||
3. **PLAN**: 一旦讨论得到一致的同意,就是开始编码的时候了。但是等等!首先,我们需要优先考虑组织我们的工作流。对于此,我们可以使用 [Issue Board][42]。
|
||||
4. **CODE**: 现在,当一切准备就绪,我们可以开始写代码了。
|
||||
5. **COMMIT**: 当我们为我们的初步成果欢呼的时候,我们就可以在版本控制下,提交代码到功能分支了。
|
||||
6. **TEST**: 通过 [GitLab CI][41],我们可以运行脚本来创建和测试我们的应用
|
||||
7. **REVIEW**: 一旦脚本成功运行,我们测试和构建成功,我们就可以进行 [code review][40] 以及批准。
|
||||
8. **STAGING:**: 现在是时候[将我们的代码部署到演示环境][39]来检查一下,是否一切就像我们预估的那样顺畅——或者我们可能仍然需要修改。
|
||||
9. **PRODUCTION**: 当项目已经运行的十分通畅,就是[部署到生产环境][38]的时候了!
|
||||
10. **FEEDBACK**: 现在是时候翻回去看我们能在项目中提升的部分了。我们使用[循环分析][37]来对当前项目中关键的部分进行的反馈。
|
||||
|
||||
简单浏览这些步骤,我们可以发现,提供强大的工具来支持这些步骤是十分重要的。在接下来的部分,我们为 GitLab 的可用工具提供一个简单的概览。
|
||||
|
||||
### GitLab 工单追踪
|
||||
|
||||
GitLab 有一个强大的工单追溯系统,在使用过程中,允许你和你的团队,以及你的合作者分享和讨论建议。
|
||||
|
||||
![issue tracker - view list](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/issue-tracker-list-view.png)
|
||||
|
||||
工单是 GitLab 工作流的第一个重要重要特性。[以工单的讨论为开始][95]; 跟随点子的改变是一个最好的方式。
|
||||
|
||||
这十分有利于:
|
||||
|
||||
* 讨论点子
|
||||
* 提交功能建议
|
||||
* 提问题
|
||||
* 提交 bug
|
||||
* 获取支持
|
||||
* 精细化新代码的引入
|
||||
|
||||
对于每一个在 GitLab 上部署的项目都有一个工单追踪器。找到你的项目中的 **Issues** > **New issue** 来创建一个新的工单。建立一个标题来总结要被讨论的主题,并且使用 [Markdown][94] 来形容它。看看 [pro tips][93] 来加强你的工单描述。
|
||||
|
||||
GitLab 工单追踪器提供了一个额外的实用功能,使得步骤变的更佳易于管理和考虑。下面的部分仔细描述了它。
|
||||
|
||||
![new issue - additional settings](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/issue-features-view.png)
|
||||
|
||||
#### 秘密工单
|
||||
|
||||
无论何时,如果你仅仅想要在团队中讨论这个工单,你可以使用 [issue confidential][92]。即使你的项目是公开的,你的工单也会被保密起来。当一个不是本项目成员的人,就算是 [Reporter level][01],想要访问工单的地址时,浏览器也会返回一个 404 错误。
|
||||
|
||||
#### 截止日期
|
||||
|
||||
每一个工单允许你填写一个[截止日期][90]。有些团队以紧凑的时间表工作,以某种方式去设置一个截止日期来解决问题,是有必要的。这些都可以通过截止日期这一功能实现。
|
||||
|
||||
当你有一个多任务的项目截止日期的时候——比如说,一个新的发布、项目的启动,或者追踪团体任务——你可以使用 [milestones][89]。
|
||||
|
||||
### 受托者
|
||||
|
||||
任何时候,一个人想要完成工单中的工作,这个工单都可以被分配个那个人。你可以任意修改被分配者,直到满足你的需求。这个功能的想法是,一个受托者本身对这个工单负责,直到其将这个工单重新赋予其他人。
|
||||
|
||||
这对于筛选每个受托者的工单也有帮助。
|
||||
|
||||
### 标签
|
||||
|
||||
GitLab标签也是GitLab流的一个重要组成部分。你可以使用它们来分类你的工单,在工作流中定位,以及通过[优先级标签][88]来组织它们。
|
||||
|
||||
标签使得你与[GitLab Issue Board][87]协同工作,加快工程进度以及组织你的工作流。
|
||||
|
||||
**New!** 你可以创建[组标签][86]。它可以使得在每一个项目组中使用相同的标签。
|
||||
|
||||
### 工单权重
|
||||
|
||||
你可以添加个[工单权重][85]使得一个工单重要性表现的更为清晰。01-03表示工单不是特别重要,07-09表示十分重要,04-06表示程度适中。此外,你可以与你的团队自行定义工单重要性的指标。
|
||||
|
||||
### GitLab工单看板
|
||||
|
||||
在项目中,[GitLab工单看板][84]是一个计划以及组织你的工单理想工具。
|
||||
|
||||
看板包含了与其相关的各自标签,每一个列表包含了相关的被标记的工单,并且以卡片的形式展示出来。
|
||||
|
||||
这些卡片可以在列表之间移动,被移动的卡片,其标签将会依据你移动的位置发生改变。
|
||||
|
||||
![GitLab Issue Board](https://about.gitlab.com/images/blogimages/designing-issue-boards/issue-board.gif)
|
||||
|
||||
**New!** 你也可以在看板右边创建工单,通过点击列表上方的按钮。当你这么做的时候,这个工单将会自动添加与列表相关的标签。
|
||||
**New!** 我们[最近被告知][83] 每一个GitLab项目拥有**多个工单看板** (仅存在于[GitLab Enterprise Edition][82]); 为不同的工作流组织你的工单,这是一个最好的方式。
|
||||
|
||||
![Multiple Issue Boards](https://about.gitlab.com/images/8_13/m_ib.gif)
|
||||
|
||||
### 通过GitLab进行代码复审
|
||||
|
||||
在工单追踪中,讨论了新的提议之后,就是在代码上做工作的时候了。你在本地书写代码,一旦你完成了你的第一个版本,你提交你的代码并且推送到你的GitLab仓库。你基于Git的管理策略可以在[GitLab流][81]中被提升。
|
||||
|
||||
### 第一次提交
|
||||
|
||||
在你的第一次提交信息中,你可以添加涉及到工单号在其中。通过这样做你可以将两个阶段的开发工作流链接起来:工单本身以及关于这个工单的第一次提交。
|
||||
|
||||
这样做,如果你提交的代码和工单属于同一个项目,你可以简单的添加 `#xxx` 到提交信息中(译者注:git commit message),`xxx`是一个工单号。如果它们不在一个项目中,你可以添加整个工单的整个URL(`https://gitlab.com/<username>/<projectname>/issues/<xxx>`)。
|
||||
|
||||
```
|
||||
`git commit -m "this is my commit message. Ref #xxx"`
|
||||
```
|
||||
|
||||
或者
|
||||
|
||||
```
|
||||
`git commit -m "this is my commit message. Related to https://gitlab.com/<username>/<projectname>/issues/<xxx>"`
|
||||
```
|
||||
|
||||
当然,你也可以替换`gitlab.com`,以你自己的GitLab实例来替换这个URL
|
||||
|
||||
**Note:** 链接工单和你的第一次提交是为了追踪你的进展,通过[GitLab Cycle Analytics][80]. 这将会衡量完成时间与计划工单的实施。这个时间是创建工单与第一次提交的间隔时间。
|
||||
|
||||
### 合并请求
|
||||
|
||||
一旦你提交你的改动到功能分支,GitLab将对定义这次修改,并且建议你提交一次合并请求(MR)。
|
||||
|
||||
每一次MR都会有一个题目(这个题目总结了这次的改动)并且一个书写自[Markdown][79]的描述。在描述中,你可以简单的描述MR做了什么,涉及到任何工单以及Mr(通过创建一个链接联系他们),并且,你也可以添加个[关闭工单模式][78],当MR被**合并**的时候,相关联的工单就会被关闭。
|
||||
|
||||
例如:
|
||||
|
||||
```
|
||||
`## 增加一个新页面
|
||||
|
||||
个MR将会为这个项目创建一个`readme.md`,此文件包含这个app的概览
|
||||
|
||||
Closes #xxx and https://gitlab.com/<username>/<projectname>/issues/<xxx>
|
||||
|
||||
预览:
|
||||
|
||||
![preview the new page](#image-url)
|
||||
|
||||
cc/ @Mary @Jane @John`
|
||||
```
|
||||
|
||||
当你创建一个带有描述的MR,就像是上文叙述的那样,它将会:
|
||||
|
||||
* 当合并时,关闭包括工单 `#xxx` 以及 `https://gitlab.com/<username>/<projectname>/issues/<xxx>`
|
||||
* 展示一张图片
|
||||
* 提醒用户 `@Mary`, `@Jane`,以及给`@John`发邮件
|
||||
|
||||
你可以分配这个MR给你自己,直到你完成你的工作,然后把他分配给其他人来做一次代码复审。如果有必要的话,这个可以被重新分配多次,直到你覆盖你所需要的所有复审。
|
||||
|
||||
它也可以被标记,并且添加一个[milestone][77]来促进管理。
|
||||
|
||||
当你添加或者修改一个文件并且提交一个新的分支,从UI而不是命令行的时候,它也一样简单。创建一个新的合并请求,仅仅需要标记一下复选框,“以这些改变开始一个新的合并请求”,然后,一旦你提交你的改动,GitLab将会自动创建一个新的MR。
|
||||
|
||||
![commit to a feature branch and add a new MR from the UI](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/start-new-mr-edit-from-ui.png)
|
||||
|
||||
**Note:** 添加[关闭工单样式][76]到你的MR来使得[GitLab Cycle Analytics][75]追踪你的项目进展,是十分重要的。它将会追踪“代码”阶段,衡量项目的时间。这个时间是第一次提交和创建一个合并请求间隔的时间。
|
||||
|
||||
**New!** 我们已经开发了[审查应用][74],一个新的功能是使得你可以部署你的应用到一个动态的环境中,来自那些你可以预览的改动。这些改动基于分支的名字,以及每一个合并请求。看看[working example][73]。
|
||||
|
||||
### WIP MR
|
||||
|
||||
一个 WIP MR,含义是 **在工作过程中的合并请求**,是一个我们在GitLab中避免MR在准备就绪前被合并的技术。只需要添加`WIP:` 在MR的标题开头,它将不会被合并,除非你把`WIP:`删除。
|
||||
|
||||
当你改动已经准备好被合并,删除`WIP:` 编辑工单来手动删除,或者使用一个快捷键,允许你在MR描述下使用。
|
||||
|
||||
![WIP MR click to remove WIP from the title](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-wip-mr.png)
|
||||
|
||||
**New!** `WIP`模式可以被[很快的添加到合并请求][72],通过[slash command][71]`/wip`。只需要输入它并且在评论或者MR描述中提交。
|
||||
|
||||
### 复审
|
||||
|
||||
一旦你创建一个合并请求,就是你开始从你的团队以及合作方收取反馈的时候了。使用UI中可用的区别功能,你可以简单的添加行中注释,来回复他们或者解决他们。
|
||||
|
||||
你也可以在每一行代码中获取一个链接,通过点击行号。
|
||||
|
||||
提交历史在UI中是可见的,通过提交历史,你可以追踪文件的每一次改变。你可以在行中浏览他们,
|
||||
|
||||
![code review in MRs at GitLab](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-code-review.png)
|
||||
|
||||
**New!** 你可以找到合并冲突,快速[通过UI界面来解决][70],或者依据你的需要修改文件来修复冲突。
|
||||
|
||||
![mr conflict resolution](https://about.gitlab.com/images/8_13/inlinemergeconflictresolution.gif)
|
||||
|
||||
### 创建,测试以及发布
|
||||
|
||||
[GitLab CI][69] 是一个强大的内建工具,其作用是[持续集成,持续发布以及持续投递][58],可以按照你希望的运行一些脚本。它的可能性是无止尽的:它就像是你自己的命令行为你工作。
|
||||
|
||||
它完全是通过Yaml文件设置的,`.gitlab-ci.yml`,放置在你的项目仓库中。使用网络,通过简单的添加一个文件,命名为`.gitlab-ci.yml`来打开一个下拉目录,为不同的应用选择各种CI模版。
|
||||
|
||||
![GitLab CI templates - dropdown menu](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-ci-template.png)
|
||||
|
||||
### Koding
|
||||
|
||||
Use GitLab's [Koding integration][67] to run your entire development environment in the cloud. This means that you can check out a project or just a merge request in a full-fledged IDE with the press of a button.
|
||||
|
||||
使用 GitLab的[Koding集成][67]去使用你整个云端开发环境。这意味着你可以通过一个完整的IDE点,点击一个按键,在一个项目中切换分支,或者合并一个请求。
|
||||
|
||||
### 使用案例
|
||||
|
||||
GitLab CI的使用案例:
|
||||
|
||||
* 使用它去[创建][36]任何[静态网站生成器][35],并且通过[GitLab Pages][34]发布你的网站。
|
||||
* 使用它来[发布你的网站][33]来`staging`以及`production`[环境][32](译者注:展示以及产品化)
|
||||
* 用它来[创建一个iOS应用][31]
|
||||
* 用它来[创建一集发布你的Docker镜像][30]通过[GitLab容器注册][29]
|
||||
|
||||
我们已经准备一大堆[GitLab CI样例工程][66]作为您的指南。看看他们吧!
|
||||
|
||||
### 反馈:循环分析
|
||||
|
||||
当你依据 GitLab工作流 工作,你的团队从点子到产品,在每一个[过程的关键部分][64],你将会即时获得一个[GitLab循环分析][65]的反馈:
|
||||
|
||||
* **Issue:** 创建一个工单到分配这个工单到一个里程碑,或者添加一个工单到你的工单看板的时间
|
||||
* **Plan:** 给工单分配一个里程碑或者把它添加到工单看板,到发布第一次提交的时间。
|
||||
* **Code:** 第一次提交到提出合并请求的时间
|
||||
* **Test:** CI为了相关合并请求,运行整个管道的时间
|
||||
* **Review:** 创建一个合并请求到合并的时间
|
||||
* **Staging:** 合并到发布成为产品的时间
|
||||
* **Production** (总的): 创建一个工单到把代码发布成[产品][28]的时间
|
||||
|
||||
### 加强
|
||||
|
||||
### 工单以及合并模版
|
||||
|
||||
[工单以及合并模版][63]允许你去定义一个关于工单的详细模版,以及合并您的项目中请求描述部分。
|
||||
|
||||
您将会把他们以[Markdown][62]形式书写,并且把他们加入您仓库的默认分支。任何时候一个工单或者MR被创建,他们都可以被一个下拉菜单访问。
|
||||
|
||||
他们节省了您在描述工单和MR,以及标准化需要持续跟踪的重要信息的时间。它确保了你需要的一切都在你的掌控之中。
|
||||
|
||||
当你可以创建许多模版,他们为不同的目的提供服务。例如,你可以有一个提供功能建议的工单模版,或者一个bug汇报的工单模版。在[GitLab CE project][61]中寻找真实的例子吧!
|
||||
|
||||
![issues and MR templates - dropdown menu screenshot](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/issues-choose-template.png)
|
||||
|
||||
### 里程碑
|
||||
|
||||
[里程碑][60] 是GitLab中追踪你队伍工作的最好工具。它基于共同的目标,详细的日期。
|
||||
|
||||
不同情况的目的是不同的,但是概述是相同的:你有一个工单的集合以及正在编码的合并请求来达到特定的目标。
|
||||
|
||||
这个目标基本上可以是任何东西——用来组合团队工作,通过一个截止日期来提高团队的工作时间。例如,发布一个新的release,启动一个新的产品,通过日期让事情完成,或者集合一些项目,使之一个季度完成。
|
||||
|
||||
![milestone dashboard](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-milestone.png)
|
||||
|
||||
### 高级要点
|
||||
|
||||
### 工单和MR
|
||||
|
||||
* 工单和MR的描述中:
|
||||
* 输入`#`来触发一个关于现存工单的下拉列表
|
||||
* 输入`!` 来触发一个关于现存MR的下拉列表
|
||||
* 输入 `/` 来触发[slash 命令][4]
|
||||
* 输入 `:` 来出发emoji表情 (也支持行中评论)
|
||||
* 添加图片(jpg, png, gif) 和视频到行中评论,通过按钮 **Attach a file**
|
||||
* [自动应用标签][27] 通过 [GitLab Webhooks][26]
|
||||
* [构成引用][24]: 使用语法 `>>>` 来开始或者结束一个引用
|
||||
|
||||
```
|
||||
`>>>
|
||||
Quoted text
|
||||
|
||||
Another paragraph
|
||||
>>>`
|
||||
```
|
||||
* Create [task lists][23]:
|
||||
|
||||
```
|
||||
`- [ ] Task 1
|
||||
- [ ] Task 2
|
||||
- [ ] Task 3`
|
||||
```
|
||||
|
||||
#### 订阅
|
||||
|
||||
你是否发现你有一个工单或者MR想要追踪?在你的右边,扩展导航中,点击[订阅][59],你就可以在任何时候收到一个评论的更新。要是你想要一次订阅多个工单和MR?使用[bulk subscription][58]. 😃
|
||||
|
||||
#### 添加代办
|
||||
|
||||
除了一直留意工单和MR,如果你想要预先做点什么,或者在任何时候你想要在GitLab 代办列表中添加什么,点击你右边的导航,并且[点击 **添加代办**][57]。
|
||||
|
||||
#### 寻找你的工单和MR
|
||||
|
||||
当你寻找一个在很久以前由你开启的工单——他们可能数以千计——所以你很难找到他们。打开你左边的导航,并且点击**工单**或者**合并请求**,你就会看到那些分配给你的。同时,在那里或者任何工单追踪器,你可以通过作者,分配者,里程碑,标签以及重要性来过滤工单,也可以通过搜索所有不同状态的工单,例如开启的,合并的,关闭的等等。
|
||||
|
||||
### 移动工单
|
||||
|
||||
一个工单在一个错误的项目中结束了?不用单机,点击**Edit**,然后[移动工单][56]到正确的项目。
|
||||
|
||||
### 代码片段
|
||||
|
||||
有时候你在不同的项目以及文件中,使用一些相同的代码段和模版吗?创建一个代码段并且使它在你需要的时候可用。打开左边导航栏,点击**[Snipptes][25]**。所有你的片段都会在那里。你可以把她们设置成公开的,内部的(仅仅为GitLab注册用户提供),或者私有的。
|
||||
|
||||
![Snippets - screenshot](https://about.gitlab.com/images/blogimages/gitlab-workflow-an-overview/gitlab-code-snippet.png)
|
||||
|
||||
### GitLab 工作流用户案例设想
|
||||
|
||||
为了全神贯注,让我们把所有东西聚在一起理顺一下。不必担心,这十分简单。
|
||||
|
||||
让我们假设:你工作于一个聚焦于软件开发的公司。你创建了一个新的工单,这个工单是为了开发一个新功能,实施于你的一个应用中。
|
||||
|
||||
### 标签策略
|
||||
|
||||
为了这个应用,你已经创建了几个标签,“讨论”,“后端”,“前端”,“正在进行”,“展示”,“就绪”,“文档”,“营销”以及“产品”。所有都已经在工单看板有他们自己的列表。你的工单已经有标签“讨论”。
|
||||
|
||||
在工单追踪器中的讨论达成一致,你的后端团队开始在工单上工作,所以他们把这个工单的标签从“讨论”移动到“后端”。第一个开发者开始写代码,并且把这个工单分配给自己,增加标签“正在进行”。
|
||||
|
||||
### 编码 & 提交
|
||||
|
||||
在他的第一次提交的信息中,他提及了他的工单编号。在工作后,他把他的提交推送到一个功能分支,并且创建一个新的合并请求,在MR描述中,包含工单关闭模式。他的团队复审了他的代码并且保证所有的测试和建立都已经通过。
|
||||
|
||||
### 使用工单看板
|
||||
|
||||
一旦后端团队完成了他们的工作,他们就删除“正在进行”标签,并且把工单从“后端”移动到“前端”看板。所以,前端团队接到通知,这个工单已经为他们准备好了。
|
||||
|
||||
### 发布到演示
|
||||
|
||||
当一个前端开发者开始为工单工作,他(她)增加一个标签“正在进行”,并且把这个工单重新分配给自己。当工作完成,这个实施将会被发布到一个**演示**环境。标签“正在进行”就会被删除,然后在工单看板里,工单卡被移动到“演示”表中。
|
||||
|
||||
### 团队合作
|
||||
|
||||
最后,当新功能引入成功,你的团队把它移动到“就绪”列表。
|
||||
|
||||
然后,就是你的技术文档编写团队的时间了,他们为新功能书写文档。一旦某个人完成书写,他添加标签“文档”。同时,你的市场团队开始启动以及推荐功能,所以某个人添加“市场化”。当技术文档书写完毕,书写者删除标签“文档”。一旦市场团队完成他们的工作,他们将工单从“市场化”移动到“生产”。
|
||||
|
||||
### 部署到生产环境
|
||||
|
||||
最后,你将会成为那个为新释出负责的人,合并“合并请求”并且将新功能部署到**生产**环境,然后工单的状态转变为**关闭**。
|
||||
|
||||
### 反馈
|
||||
|
||||
通过 [循环分析][55],你和你的团队节省了如何从点子到产品的时间,并且开启另一个工单,来讨论如何将这个过程进一步提升。
|
||||
|
||||
### 总结
|
||||
|
||||
GitLab 工作流 通过一个平台,帮助你的团队加速从点子到生产的改变:
|
||||
|
||||
* 它是**有效的**:因为你可以获取你想要的结果
|
||||
* 它是**效率高的**:因为你可以用最小的努力和话费达到最大的生产力。
|
||||
* 它是**高产的**:因为你可以非常有效的计划和行动
|
||||
* 它是**简单的**:因为你不需要安装不同的工具去完成你的目的,仅仅需要GitLab
|
||||
* 它是**快速的**:因为你不需要跳过多个平台来完成你的工作
|
||||
|
||||
每月的22号都会有一个新的GitLab版本释出,来让它变的更好的称谓集成软件开发方法,并且让团队在一个单一的,唯一的界面一起工作。
|
||||
|
||||
在GitLab,每个人都可以奉献!多亏了我们强大的社区,我们获得了我们想要的。并且多亏了他们,我们才能一直为你提供更好的产品。
|
||||
|
||||
还有什么问题和反馈吗?请留言,或者在推特上@我们[@GitLab][54]!🙌
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/
|
||||
|
||||
作者:[Marcia Ramos][a]
|
||||
|
||||
译者:[svtter](https://github.com/svtter)
|
||||
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://twitter.com/XMDRamos
|
||||
[1]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#search-for-your-issues-and-mrs
|
||||
[2]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#add-to-do
|
||||
[3]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#subscribe
|
||||
[4]:https://docs.gitlab.com/ce/user/project/slash_commands.html
|
||||
[5]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#code-snippets
|
||||
[6]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#moving-issues
|
||||
[7]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#for-both-issues-and-mrs
|
||||
[8]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#milestones
|
||||
[9]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#issue-and-mr-templates
|
||||
[10]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#use-cases
|
||||
[11]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#koding
|
||||
[12]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#review
|
||||
[13]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#wip-mr
|
||||
[14]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#merge-request
|
||||
[15]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#first-commit
|
||||
[16]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-board
|
||||
[17]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#issue-weight
|
||||
[18]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#labels
|
||||
[19]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#assignee
|
||||
[20]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#due-dates
|
||||
[21]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#confidential-issues
|
||||
[22]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#stages-of-software-development
|
||||
[23]:https://docs.gitlab.com/ee/user/markdown.html#task-lists
|
||||
[24]:https://about.gitlab.com/2016/07/22/gitlab-8-10-released/#blockquote-fence-syntax
|
||||
[25]:https://gitlab.com/dashboard/snippets
|
||||
[26]:https://docs.gitlab.com/ce/web_hooks/web_hooks.html
|
||||
[27]:https://about.gitlab.com/2016/08/19/applying-gitlab-labels-automatically/
|
||||
[28]:https://docs.gitlab.com/ce/ci/yaml/README.html#environment
|
||||
[29]:https://about.gitlab.com/2016/05/23/gitlab-container-registry/
|
||||
[30]:https://about.gitlab.com/2016/08/11/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/
|
||||
[31]:https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/
|
||||
[32]:https://docs.gitlab.com/ce/ci/yaml/README.html#environment
|
||||
[33]:https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/
|
||||
[34]:https://pages.gitlab.io/
|
||||
[35]:https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/
|
||||
[36]:https://about.gitlab.com/2016/04/07/gitlab-pages-setup/
|
||||
[37]:https://about.gitlab.com/solutions/cycle-analytics/
|
||||
[38]:https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/
|
||||
[39]:https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/
|
||||
[40]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-code-review
|
||||
[41]:https://about.gitlab.com/gitlab-ci/
|
||||
[42]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-board
|
||||
[43]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-tracker
|
||||
[44]:https://about.gitlab.com/2015/08/18/gitlab-loves-mattermost/
|
||||
[45]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#conclusions
|
||||
[46]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow-use-case-scenario
|
||||
[47]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#pro-tips
|
||||
[48]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#enhance
|
||||
[49]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#feedback
|
||||
[50]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#build-test-and-deploy
|
||||
[51]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#code-review-with-gitlab
|
||||
[52]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-tracker
|
||||
[53]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow
|
||||
[54]:https://twitter.com/gitlab
|
||||
[55]:https://about.gitlab.com/solutions/cycle-analytics/
|
||||
[56]:https://about.gitlab.com/2016/03/22/gitlab-8-6-released/#move-issues-to-other-projects
|
||||
[57]:https://about.gitlab.com/2016/06/22/gitlab-8-9-released/#manually-add-todos
|
||||
[58]:https://about.gitlab.com/2016/07/22/gitlab-8-10-released/#bulk-subscribe-to-issues
|
||||
[59]:https://about.gitlab.com/2016/03/22/gitlab-8-6-released/#subscribe-to-a-label
|
||||
[60]:https://about.gitlab.com/2016/08/05/feature-highlight-set-dates-for-issues/#milestones
|
||||
[61]:https://gitlab.com/gitlab-org/gitlab-ce/issues/new
|
||||
[62]:https://docs.gitlab.com/ee/user/markdown.html
|
||||
[63]:https://docs.gitlab.com/ce/user/project/description_templates.html
|
||||
[64]:https://about.gitlab.com/2016/09/21/cycle-analytics-feature-highlight/
|
||||
[65]:https://about.gitlab.com/solutions/cycle-analytics/
|
||||
[66]:https://docs.gitlab.com/ee/ci/examples/README.html
|
||||
[67]:https://about.gitlab.com/2016/08/22/gitlab-8-11-released/#koding-integration
|
||||
[68]:https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/
|
||||
[69]:https://about.gitlab.com/gitlab-ci/
|
||||
[70]:https://about.gitlab.com/2016/08/22/gitlab-8-11-released/#merge-conflict-resolution
|
||||
[71]:https://docs.gitlab.com/ce/user/project/slash_commands.html
|
||||
[72]:https://about.gitlab.com/2016/10/22/gitlab-8-13-released/#wip-slash-command
|
||||
[73]:https://gitlab.com/gitlab-examples/review-apps-nginx/
|
||||
[74]:https://about.gitlab.com/2016/10/22/gitlab-8-13-released/#ability-to-stop-review-apps
|
||||
[75]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#feedback
|
||||
[76]:https://docs.gitlab.com/ce/administration/issue_closing_pattern.html
|
||||
[77]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#milestones
|
||||
[78]:https://docs.gitlab.com/ce/administration/issue_closing_pattern.html
|
||||
[79]:https://docs.gitlab.com/ee/user/markdown.html
|
||||
[80]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#feedback
|
||||
[81]:https://about.gitlab.com/2014/09/29/gitlab-flow/
|
||||
[82]:https://about.gitlab.com/free-trial/
|
||||
[83]:https://about.gitlab.com/2016/10/22/gitlab-8-13-released/#multiple-issue-boards-ee
|
||||
[84]:https://about.gitlab.com/solutions/issueboard
|
||||
[85]:https://docs.gitlab.com/ee/workflow/issue_weight.html
|
||||
[86]:https://about.gitlab.com/2016/10/22/gitlab-8-13-released/#group-labels
|
||||
[87]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-issue-board
|
||||
[88]:https://docs.gitlab.com/ee/user/project/labels.html#prioritize-labels
|
||||
[89]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#milestones
|
||||
[90]:https://about.gitlab.com/2016/08/05/feature-highlight-set-dates-for-issues/#due-dates-for-issues
|
||||
[91]:https://docs.gitlab.com/ce/user/permissions.html
|
||||
[92]:https://about.gitlab.com/2016/03/31/feature-highlihght-confidential-issues/
|
||||
[93]:https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#pro-tips
|
||||
[94]:https://docs.gitlab.com/ee/user/markdown.html
|
||||
[95]:https://about.gitlab.com/2016/03/03/start-with-an-issue/
|
||||
[96]:https://about.gitlab.com/2016/09/13/gitlab-master-plan/
|
||||
[97]:https://about.gitlab.com/2014/09/29/gitlab-flow/
|
Loading…
Reference in New Issue
Block a user