# 自动化构建项目（DevOps CI/CD）

# 第一章 课程目的

# 一、企业开发流程

自学、培训，一门语言结束后，不知道企业开发流程。

本课程分享企业工作中，个人工作开发部署的经验。

# 二、注重实操

读万卷书不如行万里路。听过太多知识，总记不住，就是因为自己没有真实写过代码、操作过流程。

所以跟着做就完事儿了！

# 三、适用人群

1 学生：实习。实习公司怎么和项目经理配合、和运维人员配合，项目上线。

2 研发：不光写代码，也需要知道项目如何上线。

3 小企业主：管理整个项目。项目有条不紊的迭代更新下去。

# 第二章 项目管理里的术语

# 一、项目管理

# 1、项目管理概念

​ 研发管理就是在研发体系结构设计open in new window和各种管理理论open in new window基础之上，借助信息平台对研发过程中进行的团队建设open in new window、流程设计、绩效管理open in new window、风险管理open in new window、成本管理open in new window、项目管理open in new window和知识管理open in new window等的一系列协调活动。

真实在企业中，开发一个项目（ydlclass），到底应该怎么做。

通过软件平台管理：团队建设，绩效管理，风险管理，成本管理，项目设计，分配任务，每日事项，知识库。

好处：是的团队更加高效完成项目。

项目管理工具（jira\teambition\禅道），代码管理（gitee\github\gitlab\svn）,运维平台（国产蓝鲸），持续交付平台（jenkins\gitlab）。

# 2、项目管理要做什么

# （1）企业开发流程：（iqiyi）

新项目、新功能

1 立项：1个项目经理，1产品经理（需求文档prd）,1UI, 2开发，1测试，1运维。

2 讨论：产品经理写出的prd文档，需求是否合理可行。

3 画静态图片：UI(ued团队)，美工。 蓝湖工具：图片jpg----》静态页面html

4 前后端接口定义： 请求 Get ip:port/user/1 响应：{code:200,data:{name:itlils,age:18}} 总结出接口文档

5 分离开发：前后端各干各的。排期 3天。

6 自测：前端电脑发来请求，后端电脑返回数据。

7 部署测试环境：让测试人员工具需求文档进行测试。

8 提交到git封板：运维部署到预发布环境。让技术和业务老大拍板。

9 上线：运维部署到生产环境。用户使用。

10 上线注意：周二、周四晚12点上线新功能。测试公网用户访问，线上出了bug了，通宵。

# 3、项目部署环境

环境

# 部署环境类型

持续集成开发环境（DEV: Development Environment） 直接通过源代码编译打包，其会跑单元测试，服务API自动化测试，服务UI自动化测试

测试环境（Test: Test Environment） 部署带版本的组件，服务API自动化测试，服务UI自动化测试

系统集成环境（SIT, System Integration Test Environment） 部署带版本的组件，服务API自动化测试，服务UI自动化测试，多系统集成API测试，多系统集成UI自动化测试。

用户可接受性测试环境（UAT, User acceptance Test Environment） 部署带版本的组件，此环境主要用来进行软件产品的验收，用户（客户方）会直接参与，用户根据需求功能文档进行验收，当然在用户验收前可以可以跑API自动化测试和UI自动化测试。此外根据客户项目合同要求，可能需要出具可接受性测试报告：包括但不限于，功能性测试报告，安全测试报告，性能测试报告等

预生产环境（STAGING, Staging Environment） 部署带版本的组件，一般在直接上生产环境之前，会进行一些基本健康测试[自动或者手工]，有的时候还会进行模拟生产环境的真实数据进行Dry Run，其Dry Run很多时候都是在正常生产环境的配置和网络条件下进行的，Dry Run之后，没有问题了，就会把预生产环境切换回来，或者直接上生产环境； 从预生产环境集群切换到生产环境集群的方法有： 蓝绿部署，A/B测试，金丝雀部署【灰度发布】等方法。

生产环境（Prod: Production Environment） 部署带版本的组件，正式生产环境。

灾备环境（DR: Disaster Recovery Environment） 部署带版本的组件，对于一些服务可用性，可连续性有特别要求，比如关系到国计民生的系统，需要进行灾备。

# 二、敏捷开发（小步快跑）

项目不是一蹴而就，功能齐全了才上线。那竞争对手早就占领了市场了。

而是先有了大体的功能之后，一个一个的小功能上线，从而变为一个完善的项目。

# Scrum

​ Scrum是迭代式增量软件开发过程open in new window，是敏捷方法论中的重要框架之一，通常用于敏捷软件开发open in new window。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程open in new window和任务，产品负责人代表利益所有者open in new window，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目open in new window而开发的，它同样可以用于运行软件维护open in new window团队，或者作为计划管理方法open in new window：Scrum of Scrums. [1]

Scrum 作为最流行的敏捷框架，这些年已经得到广泛的流行。但是很多团队在落地Scrum的时候并不总是一帆风顺。

# 1、 什么样的团队适合实施Scrum？

通常来说，国内最常见的开发管理模式有四种：

• 敏捷开发
• 瀑布开发
• 看板（指精益看板）
• 混合模式

其中，Kanban（看板）对于需求变化非常快的项目更有优势，比如连一周的迭代都没办法保证的特性开发，或者属于支持/维护类的项目团队。此外，看板对于不喜欢对现状改变太大的企业，更加容易被接受。

而相对来说，对于那些有着清晰roadmap的特性开发团队，以便于按照固定的节奏提交价值增量，Scrum更加有完整的套路。

瀑布模型一般适用于需求在规划和设计阶段就已确定，且项目开发周期内需求没有或极少变化，对需求变更进行严格控制，例如航空航天、金融核心系统等；以及稳定的低风险项目（对目标、环境非常熟悉），规模小实现简单易受控的项目等特点的项目；

# 2、 Scrum 框架构成及实施全流程

Scrum 框架包括：3个角色、3个工件、5个活动和5个价值观。

# 2.1 3个角色

• Scrum Master

作为 Scrum 流程的捍卫者和布道者，ScrumMaster在Scrum团队中起到至关重要的作用，他们确保团队使用正确的流程，确保团队正确地召开各种会议，帮助每个人理解Scrum 理论、实践、规则和价值。

Scrum Master 对Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助Scrum 团队之外的人了解他/她如何与Scrum 团队交互是有益的，通过改变他/她们与Scrum 团队的互动方式来最大化Scrum 团队所创造的价值。

• Product Owner

产品负责人（Product Owner）是有授权的产品领导力核心，组成Scrum团队三个角色之一。PO担任的是产品经理的角色。

作为确保团队做出正确产品，以便帮公司得到最高投资回报的产品负责人，在Scrum团队中负责“做什么”的问题。但不同公司，不同部门，不同团队的产品负责人的具体职责不尽相同。从总体上来说，产品负责人要负责产品的愿景和边界。而具体来说，产品负责人的工作是提出正确的解决方案和确保解决方案被正确“制造”。

• Team（开发团队）

在Scrum开发团队，所有的人都被称为“工程师”，且人数不宜过多，5~7人比较理想，包含产品、设计、前端、后端、测试等多角色，是实际价值产出者；

在 Scrum 的每个冲刺当中，开发团队为了实现计划里的功能，他们必须完成所有的相关工作，包括产品设计，开发，集成和测试。为此，团队必须具备完成这些工作的所有技能。在工作中，Scrum 作为一个整体，对功能的实现负责。区别于传统开发方法里的“只负责自己那一部分工作”的状态。

所以在团队开始之前就要考虑：为了能够完成Scrum电子任务板项目的各种需求，团队需要具备哪些能力，哪些能力是已经具备的呢，哪些能力是我们可以从外部获得支持。”

Scrum开发团队的主要职责如下：

• 在冲刺执行期间，开发团队完成创造性的工作，包括设计，构建，集成，测试，最终提供潜在可发布的功能发布。
• 每日检视和调整（每日站会）——作为一个自组织的团队，团队通过每日站会来实现自我的检视和调整以实现冲刺目标。
• 梳理产品列表——帮助产品负责人梳理产品列表，细化产品列表条目，估算和排列优先级。
• 冲刺规划——在每个冲刺之初，开发团队参与冲刺计划会议。在会议上，根据产品经理提供的信息，对产品列表条目的工作量进行估算，并在ScrumMaster的指导下，与产品负责人共同制订冲刺目标。
• 检视和调整产品与过程——在每个冲刺结束的时候，开发团队都需要参加冲刺评审会议和冲刺回顾会议。在会议上，Scrum团队检视和调整自己的过程和技术以进一步改善团队使用Scrum来交付业务价值的能力。

注意，开发团队对工作量的估算有绝对话语权，作为一个自组织的团队，他们不受其他角色的影响，对工作量进行估算并且按照自己的承诺去履行冲刺目标。

# 2.2 3个工件

• Product Backlog（产品待办列表）

首先产品待办列表永远不会完成，它是产品所有已知需求的优先级排序表，为了确保产品是有用的、有竞争力的，列表会不断地变化和调整，例如当市场提供了一些反馈，需求可能会变得更详细，PO就需要根据业务需要、市场环境和技术的变化及时进行调整，所以我们说，产品待办列表是动态的，会随着产品和使用它的环境发展而发展。

• Sprint Backblog

Sprint列表是团队当前Sprint的任务清单。和产品列表不一样，它的寿命是有限的，仅在一个Sprint的时间里存活。它里面包含所有团队已承诺的故事以及相关联的任务，以及此外的附加工作，例如，在回顾会议中所发现的团队改进任务，团队计划要在当前Sprint完成。

Sprint列表在Sprint规划会议中产生，一旦Sprint规划会议结束，产品负责人就不能再修改Sprint列表的故事清单了。这是Scrum中业务方和开发团队之间的基本协议，每次Sprint开始前，业务方都可以改变方向，然而Sprint开始以后，团队则会专注于他们所承诺完成的故事。改变这个已承诺的故事清单只有一个方式，就是由干这个活儿的团队成员提出变更请求。

• Increment（增量）

Increment是Sprint期间完成的所有Product Backlog项目的总和，以及所有先前Sprint的增量值。在Sprint结束时，新增量必须是“完成”，这意味着它必须处于可用状态并符合Scrum团队对“完成”的定义。增量是一个可检查的“完成”工作，支持经验主义在Sprint结束时。增量是迈向愿景或目标的一步。无论产品负责人是否决定释放，增量必须处于可用状态。

Scrum的全部意义在于提供“完成”增量。

• 扩展工件之燃尽图

冲刺燃尽图（或燃尽图）不是官方的 Scrum 工件，但许多团队在冲刺期间使用它来沟通和跟踪冲刺目标的进度。燃尽图是显示在冲刺期间完成的任务的图表。燃尽图在帮助衡量团队的积极执行速度方面非常有用，因此他们知道他们是否会完成计划或需要重新确定冲刺任务的优先级。

在 sprint 计划期间，团队可以查看之前的燃尽图，以了解他们可以在即将到来的 sprint 中实际完成多少任务。团队可以检查正在进行的燃尽图，以确定他们是否能够成功完成冲刺。

在 sprint 评审期间，团队可以重新查看燃尽图，看看他们在哪里达到或没有达到预期。随着时间的推移，燃尽图可以帮助团队在 Scrum 的计划阶段更好地改进他们的估计。

# 2.3 5个活动

• Sprint（冲刺）

冲刺（有的公司叫班车，从起点站发车，到一站后需求完成下车，新需求上车，迭代的过程以此往复），一个固定的时间周期（通常为2w~4w，新项目可以是1w）。

• Sprint planning meeting（冲刺计划会）

Sprint计划会议的主要目的是，为了完成产品待办列表的目标，需要设计一个有弹性的计划来引导开发过程，来规划我们做什么和如何做这些事，Scrum Master要确保会议顺利举行，保证每个参会者都理解会议的目的。

Sprint计划会议要求Scrum团队协同合作，共同制定，PO、SM、开发团队都要参与，不能由他人代替。在计划会议上，我们要讨论出这三个问题的答案：

1. 第一个问题是我们这次Sprint的目标是什么？
2. 第二个问题是这次Sprint开发什么功能？
3. 最后是我们将如何去做？

• Daily standup meeting（每日站会）

每日站会的目的是通过对比前次每日站会后的工作，也就是过去24小时所完成的工作，检视Sprint目标的完成度，并规划未来24小时的工作，通过每天这样快速反馈的循环，优化团队协调合作和表现。

那么这15分钟的会我们怎么开呢？

会议需要聚焦在Sprint目标上，主要通过回答以下三个问题展开：

1. 昨天我做了什么事情帮助开发团队达成Sprint目标？
2. 今天我要做什么帮助开发团队达成Sprint目标？
3. 是否有任何障碍在阻碍我或开发团队达成Sprint目标？

• Sprint review（评审会）

Sprint 评审会议在 Sprint 快结束时举行 ，这个事件是让开发团队展示他们在Sprint中取得的成就，根据DoD“完成的定义”和验收标准，验证增量，这些增量应该是：已经开发、测试完成、经过整合的和已经记录的。

Sprint 评审会议不是一个进度汇报会议，所以不推荐大家使用PPT，这是一个非正式会议，演示增量的目的是为了获取反馈，提出意见和促进合作，根据完成情况和Sprint期间产品待办列表的变化，团队和利益相关方一起讨论接下来可能要做的事情，未来有可能迎接哪些新的机会/挑战。

比如我们自己的一个Sprint评审会议过程：

1. 首先，会议开始，PO欢迎利益相关者来参加评审，然后由PO介绍项目的目标，以及本次Sprint的目标，根据我们在计划会议定义好的DoD，说明产品待办列表里哪些已经“完成”和哪些没有“完成”；
2. 展示产品增量，开发团队演示Sprint中已实现的产品新功能，最好在接近生产环境的设备上进行，例如，开发在手机APP端的功能程序应该在手机端演示，而不是电脑~
3. 由来自各方代表的利益相关者提出问题或反馈。
4. 开发团队解答交付增量的问题，并总结Sprint期间做得好和还可以改进的地方。
5. 参会的所有人就下一步的工作进行探讨： 评审产品在未来的不同市场，评估潜在的使用场景，决定接下来我们要做的哪些最有价值的改变或优化；
6. 更新产品待办事项列表，在大家讨论期待发布产品的时间、预算和市场潜力等等问题，达成共识后，会更新待办列表。也就是Sprint评审会议的输出，是这份修订后的产品待办列表，为接下来的Sprint 计划会议提供有价值的输入信息。

• Retrospective meeting

回顾会议发生在评审会议之后，下一个Sprint计划会议之前。回顾会议的时间盒，以一个月的Sprint来说，回顾会议不超过3小时，半个月的Sprint，回顾会议不超过1.5小时。

回顾会议由Scrum团队检视自身在过去的Sprint的表现，包括人 、关系、过程、工具等，思考在下一个Sprint中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。

Scrum Master作为Scrum团队成员需要来参加会议，因为TA对Scrum的流程负责。该会议主要围绕以下问题展开：

1. 我们在上一个Sprint中哪里做得好？
2. 接下来才是讨论我们哪里做得不够好？
3. 第三个问题就是，我们的改进计划是什么？
4. 我们上次计划的改进项目进度如何？

# 2.4 价值观

# 3、 Scrum实施全流程

基于以上框架，团队实施Scrum的流程如下：

# 4、Scrum 实施是否需要管理工具？好的工具有哪些？

根据国外机构 Digital.aiopen in new window 2021年发布的《第十五次敏捷状态报告》显示：自疫情发生以来，采用敏捷的软件开发团队有显著增长，从2020年的37%增加到了2021年的84%。

除此以外，从敏捷状态调查的早期开始，工具支持一直是决定敏捷成功的关键因素。在实行敏捷的团队中有各种各样的工具集被应用，覆盖从通用规划与管理工具(例如，Microsoft Office)到专门的商业产品（例如，PingCode、Jira）。

延伸阅读《2022年14个最佳 Scrum 工具盘点》*：*

https://worktile.com/blog/du-you-na-xie-hao-yong-de-scrumguan-li-gong-ju/open in new window

# 5、Scrum 落地的13个常见的坑

SCRUM 作为最流行的敏捷框架，这些年已经得到广泛的流行。但是很多团队在落地SCRUM的时候，通常会产生以下问题。

概念性问题

• SCRUM就是敏捷么？
• SCRUM就是开各种会么？
• SCRUM有什么好的，能对我的团队产生什么作用？

SCRUM执行过程问题

计划会和需求评审会有啥区别？计划会时候发现需求经常有问题，并且还会有很多问题在迭代中出现。

• 站会为什么要每天开，每天重复3个问题很乏味。
• 评审会，业务方没空参加，时间也很紧张了，会议干脆被省掉了。
• 回顾会，回顾了几次后，已经没有了热情，总是那几个问题，有什么好回顾的。
• 迭代周期如何定？版本发布怎么做？
• 为什么看起来SCRUM没什么内容，落地执行却问题多多？

SM的角色和发展问题

• SM一定是全职的么？
• SM对我的职业发展有什么帮助？
• SM的发展路径是什么？

# 三、DevOps

​ DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序open in new window/软件工程）、技术运营和质量保障（QAopen in new window）部门之间的沟通、协作与整合。

​ 它是一种重视“软件开发open in new window人员（Dev）”和“IT运维open in new window技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付open in new window”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

​ 它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品open in new window和服务，开发和运维工作必须紧密合作。

注意：1 运维人员：运维就要失业了！学编程。

​ 2 开发人员：也得懂运维的一些技术了。自学、培训的朋友，linux需要学习，懂得企业开发流程，运维的技术docker、k8s。

​ tail -100f info.log

​ 3 企业主：招聘，招全栈工程师。即会前端、后端、运维、测试。

# 1、DevOps是什么？怎么解释？

它是英文单词Development和Operations的组合。DevOps是一组最佳实践，强调IT专业人员（开发人员，操作人员，支持人员等）在应用和服务生命周期中的协作和沟通；强调整个组织合作以及交付和基础设施变更的自动化，从而实现持续集成、持续部署和持续交付。

# 2、DevOps背景是什么？

DevOps概念早先升温于2009年的欧洲，因传统模式的运维之痛而生，为了填补开发端、测试端、运维端之间的信息鸿沟，改善团队之间的协作关系。换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。

# 3、DevOps能解决什么问题？

Devops在持续、快速的交付产品的情况下，同时又能保持产品的稳定性。解决开发人员和运维人员之间矛盾。

# 4、开发和运维人员的矛盾是什么？

首先说一下这两个岗位的职责：

● 开发是实现需求

● 运维是保持产品/系统的稳定

但随着新需求越来越多，逼着开发快速实现功能，所以在开发提速的过程中，就会导致产品的不稳定，但是运维人员最重视的就是产品稳定，也就导致了开发和运维的矛盾，所以DevOps诞生了。

# 5、DevOps是工具？是方法？还是思想？

DevOps是一个平台，它是吸收了“敏捷开发”和“精益生产”的思想和方法，同时又把从【开发→测试→部署→运维】这条流水线上的所有工具整合在一起的平台。

换句话说，DevOps希望做到的是产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。

# 6、DevOps和敏捷开发的区别是什么？

区别在于敏捷解决局部问题，DevOps解决整体问题：

● 敏捷开发解决了产品快速上线的问题，不负责运维的部分

● DevOps解决了整个项目流程问题，从【开发→测试→部署上线→运维】

# 7、为什么DevOps突然发展迅猛？

主要有两点原因：

● 技术条件成熟了

DevOps随着新兴的容器技术+自动化运维工具，把以前理想技术在现实中应用了

● 来自市场的外部需求

世界变化的速度太快了，能否让公司的IT配套方案及时跟上市场需求的步伐，在今天显得至关重要。比如出租车业务中的Uber、酒店连锁行业中的Airbnb、图书经销商Amazon等。

# 8、DevOps团队工作效率能提高多少？

真正能够实践DevOps的团队也会为自身的业务带来巨大的提升。根据Puppt 2017年的报告，应用DevOps的团队将部署频率提高 46 倍，交付速度提高 440 倍。

# 9、目前哪些公司已经在使用DevOps？

自2009年提出DevOps的概念起，很多公司都开始实施 DevOps：

● 国外比较著名的有Adobe、Apple、Airbnb、Amazon(亚马逊)、Google（谷歌）、Ebay（易贝）、Etsy、Facebook、Linked In（领英）、NASA、Starbucks（星巴克）、Target（泛欧实时全额自动清算系统）、Walmart（沃尔玛）、Sony（索尼）等，Amazon是DevOps最佳实践的最有说服力的代表之一。

● 国内著名的有华为、阿里、腾讯、百度、中国银行、招商银行、华夏银行、中国工商银行、中国民生银行、中国农业银行、国家开发银行等。

# 10、DevOps为什么会继续火下去？

● 条件成熟：技术配套发展

技术的发展使得DevOps有了更多的配合。早期时，大家虽然意识到了这个问题的，但是苦于当时没有完善丰富的技术工具，是一种“理想很丰满，但是现实很骨感”的情况。

DevOps的实现可以基于新兴的容器技术；也可以在自动化运维工具Puppet、SaltStack、Ansible之后的延伸；还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。

● 来自市场的外部需求：这世界变化太快

IT行业已经越来越与市场的经济发展紧密挂钩，IT将会由支持中心变成利润驱动中心。事实上，这个变化已经开始了，这不仅体现在Google、苹果这些大企业中，而且也发生在传统行业中，比如出租车业务中的Uber、酒店连锁行业中的Airbnb、图书经销商Amazon等等。能否让公司的IT配套方案及时跟上市场需求的步伐，在今天显得至关重要。

● 来自团队的内在动力：工程师也需要

对于工程师而言，他们也是DevOps的受益者。微软资深工程师Scott Hanselman说过“对于开发者而言，最有力的工具就是自动化工具”，工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行；正如Amazon的VP兼CTO Werner Vogels那句让人印象深刻的话：“谁开发谁运行”。（You build it, you run it）

# 11、哪些因素可能促使一个组织引入DevOps？

● 使用敏捷或其他软件开发过程与方法

● 业务负责人要求加快产品交付的速率

● 虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍

● 数据中心自动化技术和配置管理工具的普及

# 12、为什么说DevOps是未来的趋势？

从大趋势上分析，未来所有企业都将是软件企业，制造软件、服务软件、构建于软件。比如全世界最大的出行公司 Uber，其实是一个软件公司，而非出租车公司。

从企业自身诉求出发，中国的中大型企业已经逐步进入了创新驱动的阶段。无论是供给侧改革还是智能制造2025都要求企业修炼内功，提高效率促进创新。过去几年中在塑造前沿行业的DevOps理念在2019年已经成为主流，成为企业能否在行业内脱颖而出的关键性因素。

真正能够实践DevOps的团队也会为自身的业务带来巨大的提升。

可见，在国际上来说，DevOps已经处于企业爆发性需求的前夜。而在国内公司中，新兴企业的成功实践也在为中国企业的DevOps输送方法论与有经验的专家。字节跳动可以说是DevOps最佳践行者之一。

今日头条、抖音、西瓜视频……字节跳动的每款App都基于这三个部门来发展。在项目开始时，公司会为每个项目设置虚拟项目组，由三个核心部门抽调人员组成，试水成功后直接推广。所有产品共用一条技术线，快速试错。针对 App 类产品的快速迭代的业务特性，字节跳动依据 DevOps 理念对组织架构进行调整和优化，从结构上保证了技术支持业务创新的能力。

# 13、DevOps未来的前景和发展趋势如何？

DevOps是不断发展的，DevOps的理念在2009年以前就提出来了，从运维开始逐步拓展到开发，现在谈DevOps已经是从端到端整体的业务形态。从发展角度来看，有很多的新技术在涌现。

有两个方面，一个是DevOps的基础框架体系是并没有改变的，依然是以敏捷、精益、轻量级的 ITSM 为基础的，这也是DevOps Master体系中重点强调的。同时也有很多的新技术在发展，在DevOps一开始提出来的时候并没有大量的提到容器或者是Docker这样的技术，但现在容器对环境包括部署，是高 绩效企业中一个不错的选择。同样有现在新兴起来的基于云上的一些方案，比较强调无服务化，service的一些功能都是DevOps技术的体现。

所以DevOps的核心和基础是没有变化的，是一个很稳定的体系，但在这之上，尤其是在实践和具体技术演进上发展是非常迅速的。

# 第三章 GitLab代码托管

# 一、GitLab介绍

GitLab是整个DevOps生命周期的第一个应用程序。其使用与GitHub类似，并且提供了许多DevOps相关的功能。GitLab提供无与伦比的可见性，更高的效率和全面的治理。这使得软件生命周期加快了200％，从根本上提高了业务速度。

官方网站:https://about.gitlab.com/open in new window

# 二、GitLab安装

# 1、拉取Gitlab镜像

1

docker pull gitlab/gitlab-ce:latest

1

docker images

# 2、启动Gitlab容器

1
2
3
4
5
6
7
8
9
10
11

docker run \
 -itd  \
 -p 9980:80 \
 -p 9922:22 \
 -v /home/gitlab/etc:/etc/gitlab  \
 -v /home/gitlab/log:/var/log/gitlab \
 -v /home/gitlab/opt:/var/opt/gitlab \
 --restart always \
 --privileged=true \
 --name gitlab \
 gitlab/gitlab-ce

1
2

# 查看docker启动
docker ps

# 3、修改配置

接下来的配置请在容器内进行修改，不要在挂载到宿主机的文件上进行修改。否则可能出现配置更新不到容器内，或者是不能即时更新到容器内，导致gitlab启动成功，但是无法访问

1
2

#进入容器内部
docker exec -it gitlab /bin/bash

1
2
3
4
5
6
7
8
9
10

#修改gitlab.rb
vi /etc/gitlab/gitlab.rb

#加入如下
#gitlab访问地址，可以写域名。如果端口不写的话默认为80端口
external_url 'http://192.168.213.128' 
#ssh主机ip
gitlab_rails['gitlab_ssh_host'] = '192.168.213.128'
#ssh连接端口
gitlab_rails['gitlab_shell_ssh_port'] = 9922

修改完成之后保存退出即可，由于咱们在dockeropen in new window中运行，在gitlab上生成的http地址应该是http://192.168.213.128:9980open in new window,所以，要修改下面文件

1
2
3
4
5
6
7

# 修改http和ssh配置
vi /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml

  gitlab:
    host: 192.168.213.128
    port: 9980 # 这里改为9980
    https: false

修改完成之后保存退出即可，重启gitlab

1
2
3
4
5

#重启gitlab 
gitlab-ctl reconfigure
gitlab-ctl restart
#退出容器 
exit

# 4、浏览器访问

路径访问：http://192.168.213.128:9980/open in new window

1

机器配置要大于4g，否则很容易启动不了，报502

第一次访问，会让修改root密码，修改后以root用户登录即可

生成默认密码在

1
2

cd /home/gitlab/etc
cat initial_root_password

登录成功后，进入主页

设置中文

右上角头像，preferences

刷新页面

# 三、GitLab使用

# 1、创建组

公司中，有很多的项目组，每个组当中很多人员参与这个项目的开发。

项目有可见性：

哪些人可以看到这个群组？ 查看文档open in new window

• 私有：群组及其项目只能由成员查看。
• 内部：除外部用户外，任何登录用户均可查看该组和任何内部项目。
• 公开：群组和任何公共项目可以在没有任何身份验证的情况下查看。

个人首页看到参与了几个组

# 2、创建人

只有管理员才能创建用户

创建新用户： itlils itnanls

修改密码：ydl666666

用户添加到项目组：

邀请用户：

# 3、创建项目

在组里创建项目\仓库

进入到项目组页面，可以看到该项目组已经关联了一个项目

# 4、ssh秘钥设置

​ 在gitlab，github上面拷贝代码时，通常用到了git clone ssh://XXX命令。其中ssh指secure shell（一种安全的网络协议），git使用这种协议进行远程加密登录。

# （1）原理

SSH登录安全性由非对称加密保证，产生密钥时，一次产生两个密钥，一个公钥，一个私钥open in new window，在git中一般命名为id_rsa.pub, id_rsa。

那么如何使用生成的一个私钥一个公钥进行验证呢？

• 本地生成一个密钥对，其中公钥放到远程主机，私钥保存在本地
• 当本地主机需要登录远程主机时，本地主机向远程主机发送一个登录请求，远程收到消息后，返回一个随机生成的字符串，本地拿到该字符串，用存放在本地的私钥进行加密，再次发送到远程，远程用之前存放在远程的公钥对本地发送过来加密过的字符串进行解密，如果解密后与源字符串等同，则认证成功。

# （2）特点

• ssh方式单独使用非对称的秘钥进行认证和加密传输，和账号密码分离开来，不需要账号也可以访问repo。
• 生成和管理秘钥有点繁琐，需要管理员添加成员的public key。不能进行匿名访问，ssh不利于对权限进行细分，用户必须具有通过SSH协议访问你主机的权限，才能进行下一步操作，比较适合内部项目

# （3）操作

1 输入ssh-keygen -t rsa，连续3次回车，成功之后id_rsa,id_rsa.pub两个文件默认在C:\Users\username/.ssh目录下，cmd运行窗口也显示了文件路径。

2 id_rsa.pub，复制所有内容

3 将ssh key填写到gitlab SSH Keys上。

# 5、IDEA操作gitlab

# （1）idea安装插件 gitlab projects插件。选择File -> Settings -> Plugins 。搜索gitlab。

# （2）设置访问令牌

​ 可以为需要访问GitLab API的每个应用程序生成个人访问令牌。您还可以使用个人访问令牌通过HTTP进行Git验证。 当您启用两步认证(2FA)时，它们将是唯一可接受的密码。idea访问gitlab专属令牌。

gitlab生成访问令牌。当点击 创建个人访问令牌后，会显示你当前的访问令牌。

idea里设置：在Idea中，选择 File -> Settings -> Version Control -> GitLab -> Add a new GitLab Server

在页面中，配置GitLab中获取到的Token相关信息

# （3）创建简单boot接口项目

写一个简单的controller

1
2
3
4
5
6
7
8
9

@RestController
@RequestMapping("demo")
public class DemoController {

    @GetMapping("test")
    public String getUser(){
        return "successs";
    }
}

# （4）项目和仓库相关联

在Idea中，选择VCS -> import into version control -> create git repository 。接着选择当前操作的工程目录文件夹即可。

# （5）文件都变红色，说明项目已经被git管理到了

# （6）git add

代码变绿

# （7）git commit

提交成功

# （8）提交代码到远程仓库

git push

设置远程仓库地址

地址从gitlab获取

注意：owner角色可以设置默认分支为master

推送失败：

因为本地项目新建的，远程仓库有readme.mdopen in new window。

所以 1删除远程仓库的readme.mdopen in new window

​ 2本地代码使用cmd输入 git pull origin master --allow-unrelated-histories

​

就可以推送成功了。

# （9）工作中代码创建流程

新人入职公司，组长告诉你gitlab地址,拉下来开发吧。

1 远程克隆项目

2 开发，写一些简单接口代码

3 每天，晚上下班前 commit push

成功了

4 第二天刚来公司，pull代码

昨晚可能别人更新过代码了

# （10）gitignore插件

方便的文件加入忽略名单

# （11）代码冲突

​ 真实的开发中，如果多个人共同开发一个模块，很容易出现代码冲突的问题。模拟解决一下。

1 小张下午5点提交了代码

2 晚上8点，小李也要提交

3 小李一推送，拒绝，发生了代码冲突

4 选择merge合并代码

真实工作中，不能简单的选择接受我的还是远程的，几百个文件。所以多个人一起讨论。

可以选择接受谁的打码。但是真实工作里，多个文件的合并需要组长来定夺。

先pull,再push，没问题了

远程改好了

# （12）版本回退

1 查看历史版本

git-show history

整个提交的时间，流程图，提交人，备注

2 回退到指定的版本

如要回退到某一个特定历史版本，右键要回退的版本 -> Copy Revision Number。

• 当前版本提交：cd3baa3d0d0d17493604d2179e58ac783ca9f2ea

  

• 要回退到的提交版本：f20b96677ed86223dd39cf3dfad430a68e865155

在打开页面中，Reset Type 选择 Hard ，to commit 输入被回退的版本号。接着点击Reset即可。

此时可以发现，本地项目中的内容已经回退到了初始化版本内容。

现在push,代码冲突。

这是因为本地和远程仓库出现冲突引起的，此时点击 cancel。接着重新 右键项目 -> Git ->Repository -> Reset HEAD。在页面中 对于 Reset Type 选择Mixed，to Commit：输入之前记录的current version。点击 Reset。接着重新进行本地和远程仓库提交操作，即可完成提交更新。查看GitLab内容如下。刚刚已经发生了一次更新。

继续reset HEAD

强力方法（不推荐） ：不解决，直接强制提交 打开Terminal，切换到项目所在目录 ，执行：git push -f

# （13）分支

拓展阅读：git 工作流

a.介绍分支

现在的操作都是对主分支操作，在工作中非常危险。

在实际项目开发中，对于master这条主分支，一般是不会让程序员随意操作的，在master这条主分支上的代码一般都是一个项目的稳定版本的功能代码，在开发的过程中，一般会另外开启一个分支，开发人员对于功能代码的提交会提交到开发分支上，当功能开发完成，在由开发分支合并到主分支，这样既有利于多人协作开发，也可以减少冲突问题的出现。

​ 在项目开发的过程中，如临时修改BUG、开发不确定是否上线的功能等，都可以创建一个分支，等待合适的时机再合并到主干master。

• master主分支，代表的是项目线上的最新代码。
• dev分支：开发接到任务的时候，需要checkout检出一些分支来，功能实现了，合并到主分支上。

b.创建分支

打开Idea，选择Git -> Repository -> Branches。选择 new Branch。即可创建一个新分支。

在弹出页面，输入新分支名称，此处叫做 dev_xiaoli。默认已经勾选了 checkout branch。代表切换到这个分支。

在自己的分支开发功能，提交代码到远程。

当进行push 时， 可以看到，当前正在使用dev_xiaoli分支。

远程也有了dev_xiaoli分支

c.切换分支

当存在多分支时，有时还需要去选择不同的分支进行操作，现在处于dev分支，要想重新切换回master分支。

右键当前项目 -> Git -> Repository -> Branches -> 选择对应分支即可。

d.合并分支

写完了一些业务逻辑之后，没问题了，要把这个功能上线。需要把dev分支合并到主分支上，操作比较危险，是小组长做的。

master修改

小李修改

合并请求，可以在页面，也可以再idea里merge

在master分支操作，把dev的改动合并到master上。

上面遇到代码冲突一样了，思路与普通代码冲突一样，沟通协调，修改什么，保留什么等。

继续尝试合并

最后推送master到远程

e.删除分支

分支代码合并到主分支之后，他就没有存在的意义了，可以删除掉。一般是组长来做。

可以在页面做，也可以在idea里做。

# 第四章 Jenkins持续集成（CI/CD）

# 一、持续集成相关概念

# 1、持续集成和持续交付

持续集成（continuous integration，CI）是一系列软件开发实践，在这一系列软件开发实践中，团队成员在短时间内将他们的更改集成到存储库中，以检测可能的错误并分析他们创建的软件质量。这是通过使用包含执行测试代码的自动持续代码检查（构建）来实现的。

另一方面，持续交付（continuous delivery，CD）是一种软件开发实践，在这种实践中，交付软件的流程是自动化的，允许在生产环境中进行短期交付。

当我们将这些流程应用到我们的微服务架构时，一定要记住，永远不应该有一个集成和发布到生产环境的“等待列表”。例如，负责服务X的团队必须能够在任何时候将更改发布到生产环境中，而不必等待其他服务的发布。图A展示了与多个团队合作时，我们的CI/CD流程应该是什么样子的高层图。

测试环境和交付准备环境的微服务CI/CD流程。在该图中，每个团队都有自己的源代码存储库、单元测试和集成测试、镜像存储库以及部署流程。这使得各个团队在部署和发布新的版本时无须等待其他发布

# 2、持续部署与持续交付

很多人认为，持续部署（continuous deployment）是持续交付（continuous delivery）的进阶状态，是指代码提交后一旦成功通过所有质量验证，就立即自动部署到生产环境中，不需要任何人的审批。事实上，“部署”与“交付”这两个主干词的意义并不相同。

“部署”是一种技术领域的操作，也就是说，从某处获取软件包，并按照预先设计的方案将其安装到计算节点上，并确保系统可以正常启动，但它并不一定意味着“必须包含业务功能的发布或交付”。“交付”则是一个业务决策活动，通常也被称为“发布”，也就是说，如果将新构建的特性交付到客户（用户）手中，用户就可以看到并使用它们。

之所以“部署”与“发布”几乎成为等价词，是历史原因造成的。很久以前，软件的发布周期较长，每次新功能部署之后就会立即发布。久而久之，“部署”就成了“发布”的代名词。为了保证软件质量，IT部门通常不允许无关代码（即与本次发布新特性集合无关，例如未开发完成的功能、不完善的功能集）被带到生产环境中。因此，每次部署就一定是重大功能的发布。

# 二、Jenkins使用说明

Jenkins是一个开源的、可扩展的持续集成、交付、部署（软件/代码的编译、打包、部署）的基于web界面的平台。允许持续集成和持续交付项目，无论用的是什么平台，可以处理任何类型的构建或持续集成。

官网：https://www.jenkins.io/zh/open in new window

官方文档：https://jenkins.io/doc/open in new window

# 1、前置软件安装

我这里使用的是 CentOS7+jdk11+maven3.5.4+jenkins2.362+git236，进行介绍 jenkins的安装与使用，在进行安装之前，服务器必须装好 jdk11 / maven3.6.2 / git236,并且配置好环境变量，并且 springboot项目的 pom文件中 maven 插件必须指定版本：

1
2
3
4
5
6
7
8
9
10
11

<plugin>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-maven-plugin</artifactId>
   <executions>
      <execution>
         <goals>
             <goal>repackage</goal>
         </goals>
      </execution>
    </executions>
</plugin>

# jdk安装

首先查看是否有安装，有安装就卸载jdk

1
2
3
4
5
6

# 查找系统是否安装jdk(root下操作)：
rpm -qa|grep jdk 或者 rpm -qa|grep java
# 卸载已安装的jdk：
yum -y remove java-1.8.0*
yum -y remove tzdata-java.noarch
yum -y remove javapackages-tools.noarch

然后开始安装jdk11

1
2
3
4
5
6
7
8
9
10
11
12
13
14

yum -y install gcc gcc-c++ autoconf pcre pcre-devel make automake
yum search jdk # 搜索一下列表
yum -y install java-11-openjdk java-11-openjdk-devel

vi /etc/profile

#加入
JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.18.0.10-1.el7_9.x86_64
JRE_HOME=$JAVA_HOME/jre
CLASS_PATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib
PATH=$PATH:$JAVA_HOME/bin:$JRE_HOME/bin
export JAVA_HOME JRE_HOME CLASS_PATH PATH

source /etc/profile

# maven安装

直接去官网下载，并配置好阿里云镜像，修改仓库路径

1
2
3
4
5
6
7
8
9
10

# 修改仓库路径
<localRepository>/usr/local/maven/repo</localRepository>

# 配置阿里镜像
<mirror>
    <id>alimaven</id>
    <mirrorOf>central</mirrorOf>
    <name>aliyun maven</name>
    <url>http://maven.aliyun.com/nexus/content/repositories/central/</url>
</mirror>

然后配置好环境变量

1
2
3
4
5
6
7
8
9
10
11
12

cat > /etc/profile.d/mvn.sh <<EOF
export MAVEN_HOME=/usr/local/maven/apache-maven-3.3.9
export PATH=\$PATH:\$MAVEN_HOME/bin
EOF
source /etc/profile.d/mvn.sh

或者，因为上面的方式再次链接服务器时，maven环境变量会失效，下面不会
vi /etc/profile 末尾追加
export MAVEN_HOME=/usr/local/maven/apache-maven-3.3.9
export PATH=$PATH:$MAVEN_HOME/bin
# 重加载
source /etc/profile

# git2.36安装

1
2
3
4
5

yum install https://repo.ius.io/ius-release-el7.rpm https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

yum -y install git236

git version

出现git版本，说明git安装完成。

# 2、jenkins安装

1 官网下载war包https://updates.jenkins.io/download/war/,我这里下载的是2.391版本，下载完成进行，上传到服务器进行启动open in new window

1

nohup java -jar jenkins.war --httpPort=8000

2 启动完成,浏览器访问ip:端口,端口默认是8000

3 linux查找密码

1

cat /root/.jenkins/secrets/initialAdminPassword

4 进行安装插件

打开 /root/.jenkins/hudson.model.UpdateCenter.xml,内容替换

1
2
3
4
5
6
7

<?xml version='1.1' encoding='UTF-8'?>
<sites>
  <site>
    <id>default</id>
    <url>https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json</url>
  </site>
</sites>

再删除文件(/root/.jenkins/updates/default.json，因为会先查找default.json中配置的插件镜像下载地址，没有才会去找hudson.model.UpdateCenter.xml中配置的镜像地址)，如果插件版本不对应，需要去插件网站下载对应版本open in new window的插件在上传 /root/.jenkins/plugins/下，然后点击 Manage Plugins -> 高级(最后一项)，选择本地文件，点击 deploy，ok搞定

建议一次下完所有依赖的插件，手动一个个装完。如果嫌弃麻烦。就在最开始的时候，选择 jenkins 推荐安装的插件，这样就不会出现依赖版本冲突的问题。安装推荐的插件。

然后重启 jenkins 继续填入初始密码与设置jenkins账号密码

注意：当前使用jenkins构建build的时候会在jenkins的根目录/root/.jenkins/下生成一个workspace文件夹,里面存放拉取下来的项目,并且打包后的jar包也在这里，jenkins配置build构建时的 pom 路径就得填写这文件夹下的项目里的pom，然后打包完后，将打包的jar包复制到我们预先创建的项目名称，流程思路就是如此这样。

安装额外的插件：登录进入首页选择菜单 Manage Plugins 进入安装 maven插件 ：Maven Integration进行安装完成后，就可以创建一个 maven项目，进行配置。

# 3、jenkins 配置

jdk设置：

git设置

maven 插件设置

# 4、构建一个item

# （1）准备工作：

步骤1：创建空的文件夹(一般以项目命名,如 mkdir /ydlweb-bakend) 步骤2：在创建的文件夹下创建一个start.shopen in new window

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#!/bin/bash
APP_NAME=ydlweb-bakend-0.0.1-SNAPSHOT.jar # 名称自定义,需要修改
PORT=8081 # 端口自定义,需要修改
PROJECT_PATH=$(cd `dirname $0`; pwd) #当前文件夹名称,不需要修改

if [ -f "$APP_NAME" ];then
  rm -rf $APP_NAME
fi

pid=`ps -ef|grep $APP_NAME|grep -v grep|awk '{print $2}' `
if [ -n "${pid}" ]; then
  kill -9 $pid
fi

# 注意 j-demo 名称需要自行修改成你自己创建的名称
cp /root/.jenkins/workspace/ydlwebtest/target/$APP_NAME $PROJECT_PATH/

nohup java -server -Xms512m -Xmx512m -Xmn128m -jar $APP_NAME > $PROJECT_PATH/nohup.out 2>&1 &

构建起名

勾选Discard old builds(丢弃旧版本)： Days to keep builds (保留构建的天数1) / Max # of builds to keep5(要保留的最大构建数5)

# item的源码

# Build Triggers(构建触发器)

勾选 Build whenever a SNAPSHOT dependency is built(构建 SNAPSHOT 依赖项时构建) -> Schedule build when some upstream has no successful builds(当某些上游没有成功构建时安排构建)

# Build(构建)

• 1.配置pom位置：/root/.jenkins/workspace/填写的工程名(填写的jenkins工程名称),如：/root/.jenkins/workspace/ydlweb-bakend
• 2.Goals and options(目标和选项)：clean package -Dmaven.test.skip=true,**注意**：前面不能有 mvn，还需要注意的是如果是聚合工程，则只需要打包依赖的工程clean install -pl j-demo -am -amd -Ptest -Dmaven.test.skip=true，这条命令只会打包 j-demo依赖的工程与j-demo工程。

# Post Steps(发布步骤)

• 1.选择 Run only if build succeeds(仅在构建成功时运行)

• 2.Add post-build step(添加构建后步骤),选择 shell.sh脚本

  1 2 3 4

  cd /ydlweb-bakend #必须设置,否则nohup.out日志文件不能生成 chmod 777 /ydlweb-bakend/start.sh sh start.sh BUILD_ID=dontKillMe /ydlweb-bakend/start.sh

说明：ydlweb-bakend是事先创建好的目录，并且目录下创建一个start.sh脚本，内容就是上边步骤2的脚本内容 其他 Build Environment(构建环境) / Pre Steps(预步骤) 等等不用填。

最后工程创建成功，就可以点击进去再点击 Build Now 进行立即构建。

查看构建日志

最后说明一下：当使用jenkins构建build的时候会在jenkins的根目录/root/.jenkins/下生成一个workspace文件夹,里面存放拉取下来的项目。

最终项目上线了

# 5、GitLab触发构建

# （1）安装 Generic Webhook Trigger 插件

# （2）配置构建

# （3） Gitlab 配置项目集成钩子，并绑定 webhook

1仓库的owner才能设置项目的webhook，切换到root

2配置只有master被push了，才发出请求

注意：新版本的gitlab不允许往本地发钩子

管理员设置一下

# （4）修改启动脚本，使得项目重启先听后起 start.shopen in new window

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#!/bin/sh
PROJECT_PATH=/root/.jenkins/workspace/ydlwebtest/target/
PROJECT_NAME=ydlweb-bakend-0.0.1-SNAPSHOT.jar
# stop process
tpid=`ps -ef|grep $PROJECT_NAME|grep -v grep|grep -v kill|awk '{print $2}'`
if [ ${tpid} ]; then
    echo 'Stop Process...'
    # 是先关闭和其有关的程序,再将其关闭
    kill -15 $tpid
fi
sleep 5

tpid=`ps -ef|grep $PROJECT_NAME|grep -v grep|grep -v kill|awk '{print $2}'`
if [ ${tpid} ]; then
    echo 'Kill Process!'
    kill -9 $tpid
else
    echo 'Stop Success!'
fi

# start process
tpid=`ps -ef|grep $PROJECT_NAME|grep -v grep|grep -v kill|awk '{print $2}'`
if [ ${tpid} ]; then
    echo 'App is already running.'
else
    echo 'App is NOT running.'

    nohup java -jar $PROJECT_PATH$PROJECT_NAME >/dev/null 2>&1 &
    echo Start Success!
    sleep 2
fi

# （5）测试下wehhook

还在刚刚配置gitlab 的集成配置页面，找到webhook 列表，点击 下拉选项里的 Push events

可以看到，jenkins 已经自动获取到webhook 的通知请求，并开始了构建

# （6）测试真实推送master分支，自动构建项目

1idea里，master分支确实commit+push

2jenkens开始下一次构建了！

3项目上线了！

# 第五章 项目管理平台

我们最后的实战项目课程使用项目管理平台，让每个学习小组的同学共同开发项目，体验企业真实开发流程，欢迎咨询。

# 一、项目管理平台作用

1 敏捷开发：提供标准敏捷研发管理，支持Scrum 与 Kanban

2 规模化敏捷：支持大型研发团队跨项目协同，实现多项目路线图规划和资源管控

3 研发工作流：连接多种工具，构建自动化研发工作流、DevOps 工作流

4 测试管理：测试用例管理和测试计划执行，确保产品交付质量

5 知识库管理：帮助企业建立规范化知识管理体系，实现文档协同与知识沉淀

# 二、分类

1 支持私有化部署： 公司比较大，有实力部署。

2 公有化平台 sass：中小公司、中小项目。

# 三、市场主流平台

1 阿里云效平台：https://devops.aliyun.com/open in new window

阿里云企业级一站式研发协同平台，数十万企业都在用。支持公共云、专有云和混合云多种部署形态，通过云原生新技术和研发新模式，助力创新创业和数字化转型企业快速实现研发敏捷和组织敏捷，打造“双敏”组织，实现多倍效能提升。

2teambition：阿里出品的项目管理平台 https://www.teambition.com/open in new window

3 PingCode：PingCode 是2021年中国软件项目管理软件榜单排名TOP1；它满足客户反馈、规划、开发、编码、构建、测试、发布上线的研发全流程管理，支持私有部署、定制开发、SAAS等版本；价格仅是Jira的30%-40%。（官网：https://sc.pingcode.com/t/n3B）open in new window

4 Worktile：Worktile 是连续多年的项目管理排行榜总榜前三。它是一个通用型的项目管理工具，支持不同类型的团队使用。项目管理方面具备项目管理、项目集管理、项目规划、项目追踪、项目文档管理等项目功能，除此以外还是一工具集合。Worktile 同样支持私有部署、二次开发、saas等版本。

5 Redmine：Redmine是一款开源的、灵活的项目管理Web解决方案。使用Ruby on Rails框架编写的，支持跨平台和跨数据库。主要功能包括：灵活的项目控制；支持多个项目；灵活的问题追踪系统；Gantt图表；新闻、文件/文档管理。（官网：http://www.redmine.org.cn/）open in new window

6 Clickup：Clickup 是国外点评网站G2排名第二的项目管理软件，它是一个为所有用户类型打造的项目管理系统，整合了所有业务流程的核心功能——销售、营销、设计和开发等。非常适合境外企业使用，但国内可能并不是最佳选择，因为不具备服务团队和服务器。（官网Click.comopen in new window）

7 Jira：Jira是全球知名软件项目管理工具，有非常多的用户认为它好，也有非常多的用户吐槽难用。它足够成熟，但学习成本也足够高。在2020年开始停止在大陆出售本地版，强迫上云。（官网：Atlassian.comopen in new window）

# 四、试用阿里云效

阿里出的一款很好用的it项目管理平台。

1 创建项目：

2 新建迭代

3 新建需求：

4 新建任务：

5 新建缺陷：

6 查看工时：

7 项目总体把控：

8 给测试人员测试任务：

9 工作项：查看自身这一天的工作量。

10 邀请成员加入企业和项目（迭代）

11总结功能

项目协作：

文档功能： 项目排期、需求文档、测试文档

知识库：

代码管理：

流水线： jenkens

制品库：nexus

应用管理：

测试管理：

云端开发：云IDE

# 五、体验一把自动构建

云效流水线 Flow 是一款企业级、自动化的持续集成和持续交付工具，通过构建自动化、集成自动化、验证自动化、部署自动化，完成从开发到上线的CI/CD全流程，帮助企业高质量、高效率的交付业务。

应用场景：没必要自建机房部署代码托管、jekens，并且自己公司的产品部署在阿里云服务器上，完全可以利用云效平台进行自动话部署。

# 1、准备环境

（1）准备一台阿里云服务器，安装java环境

1

yum install java-1.8.0-openjdk.x86_64

（2）新建代码库：

将ydlwebcackend项目，推送到codeup代码管理中，类似gitlab。

代码如果和其他仓库链接，.git删除即可。

把本地仓库和codeup关联

1
2
3
4
5
6

cd existing_folder
git init
git remote add origin https://codeup.aliyun.com/63eb4cafdd226be228e4cd72/web/ydlwebbackend.git
git add .
git commit
git push -u origin master

初始化成功

pom中修改生成jar包名 application.jar

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<build>
        <finalName>application</finalName>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>2.4</version>
            </plugin>
            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.8.5</version>
                <executions>
                    <execution>
                        <id>default-prepare-agent</id>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>default-report</id>
                        <phase>verify</phase>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

添加启动脚本deploy.shopen in new window

真实生产环境，肯定是使用sh脚本启停我们的项目，所以这个项目的启停脚本写好在根目录，推送

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103

#!/bin/bash

# 修改APP_NAME为云效上的应用名
APP_NAME=application


PROG_NAME=$0
ACTION=$1
APP_START_TIMEOUT=20    # 等待应用启动的时间
APP_PORT=8081          # 应用端口
HEALTH_CHECK_URL=http://127.0.0.1:${APP_PORT}/demo/test  # 应用健康检查URL
APP_HOME=/home/admin/${APP_NAME} # 从package.tgz中解压出来的jar包放到这个目录下
JAR_NAME=${APP_HOME}/target/${APP_NAME}.jar # jar包的名字
JAVA_OUT=${APP_HOME}/logs/start.log  #应用的启动日志

# 创建出相关目录
mkdir -p ${APP_HOME}
mkdir -p ${APP_HOME}/logs
usage() {
    echo "Usage: $PROG_NAME {start|stop|restart}"
    exit 2
}

health_check() {
    exptime=0
    echo "checking ${HEALTH_CHECK_URL}"
    while true
        do
            status_code=`/usr/bin/curl -L -o /dev/null --connect-timeout 5 -s -w %{http_code}  ${HEALTH_CHECK_URL}`
            if [ "$?" != "0" ]; then
               echo -n -e "\rapplication not started"
            else
                echo "code is $status_code"
                if [ "$status_code" == "200" ];then
                    break
                fi
            fi
            sleep 1
            ((exptime++))

            echo -e "\rWait app to pass health check: $exptime..."

            if [ $exptime -gt ${APP_START_TIMEOUT} ]; then
                echo 'app start failed'
               exit 1
            fi
        done
    echo "check ${HEALTH_CHECK_URL} success"
}
start_application() {
    echo "starting java process"
    nohup java -jar ${JAR_NAME} > ${JAVA_OUT} 2>&1 &
    echo "started java process"
}

stop_application() {
   checkjavapid=`ps -ef | grep java | grep ${APP_NAME} | grep -v grep |grep -v 'deploy.sh'| awk '{print$2}'`

   if [[ ! $checkjavapid ]];then
      echo -e "\rno java process"
      return
   fi

   echo "stop java process"
   times=60
   for e in $(seq 60)
   do
        sleep 1
        COSTTIME=$(($times - $e ))
        checkjavapid=`ps -ef | grep java | grep ${APP_NAME} | grep -v grep |grep -v 'deploy.sh'| awk '{print$2}'`
        if [[ $checkjavapid ]];then
            kill -9 $checkjavapid
            echo -e  "\r        -- stopping java lasts `expr $COSTTIME` seconds."
        else
            echo -e "\rjava process has exited"
            break;
        fi
   done
   echo ""
}
start() {
    start_application
    health_check
}
stop() {
    stop_application
}
case "$ACTION" in
    start)
        start
    ;;
    stop)
        stop
    ;;
    restart)
        stop
        start
    ;;
    *)
        usage
    ;;
esac

# 2、新建流水线

# （1）新建流水线

1. 进入云效 > 流水线 Flow 首页 > 我的流水线，单击 新建流水线，打开 选择流水线模板弹窗，选择对应的开发语言，可以查看当前语言下的默认流水线模板，可以根据模板快速创建流水线。
2. 单击 Java，选择 Java · 构建、部署到阿里云ECS/自有主机模板，单击创建，进入流水线编辑页面。

# （2）编排流水线

1. 进入流水线编辑页 > 流程配置，打开 添加流水线源，选择 示例代码源，默认选中 Java 代码类型，自动填充代码仓库地址、默认分支、工作目录等。
2. 单击 添加，流水线源区域便会出现已添加的流水线源。

# （3）配置构建任务

1. 单击 Java 构建上传任务，打开任务配置面板。
2. 查看java构建步骤配置，可按需修改。
3. 查看 构建物上传步骤配置，可按需修改。本例中，需要将target/application.jar和deploy.sh两个文件打包到制品中，打包路径按下图配置。

需要将target/application.jar和deploy.sh两个文件打包到制品中。因此需要在构建任务中按下面的方式进行配置：

# （4）配置部署任务

• 接下来配置主机部署任务，在制品下拉框中选择“制品名称.default”，也就是前面的“Java构建上传”步骤归档的那个制品。为了配置主机组，需要先创建一个，点击“新建主机组”。
• 

主机部署配置

部署脚本:需要运行启停脚本

• a.下载路径：表示希望把”构建上传”任务中的压缩包下载到机器上的什么位置，在本例的值为：/home/admin/app/package.tgz
• b.执行用户：希望以是哪个用户的身份进行脚本执行，本例的值为：root
• c.部署脚本：在机器上执行脚本的具体内容，本例的值为：

1
2
3
4

mkdir -p /home/admin/application
tar zxvf /home/admin/app/package.tgz -C /home/admin/application/
chmod 777 /home/admin/application/deploy.sh
sh /home/admin/application/deploy.sh restart

3运行流水线

上述配置完成，单击 保存并运行，可以看到 保存成功 提示，并打开 运行配置弹窗。默认 master分支，单击 运行即可触发流水线运行，进入流水线运行页。

4查看部署情况

1. 进入流水线运行页面，可以查看流水线运行进度和结果。单击 Java 构建上传任务卡片上的日志可以查看构建日志。
2. 单击 主机部署任务卡片上的 部署详情可以查看部署单详情：部署耗时、部署状态、日志等。部署状态为已完成即项目发布完成。

# （5）验证项目是否启动

公网访问http://47.94.223.175:8081/demo/testopen in new window

# （6）推送代码触发构建

流水线配置中，开启代码触发

测试一下

测试真实代码提交：

push

访问：http://47.94.223.175:8081/demo/testopen in new window

# （7）回滚

如果发布完成之后发现线上服务有问题，则需要快速回滚。云效Flow提供了通过历史版本直接进行回滚的能力。

在流水线运行页面点击”部署历史“，然后选择相应的部署任务，便可以看到该部署任务所有的成功部署记录

点击版本4的”回滚“，即可回滚到该版本

# （8）通知

为了更好的进行协作，Flow提供了通知能力在流水线不同的生命周期节点上进行通知。一般来讲开发团队会关心部署的成功和失败，那么可以将该事件推送到团队的钉钉群中，配置方式如下，点击”添加插件”，选择钉钉机器人通知，填入webhook地址，运行时机选择”失败“，”成功”

再次运行之后，就会收到相应的通知：