卓信数据-文档中心

八. DevOPS与工具集

在软件开发生命周期各个阶段，尽可能统一工具，工具只是支撑，关键在于提升人与人之间的协同效率，降低沟通理解成本。

DevOPS是一个持续闭环，包括 ：规划(Plan)、编码(Code),构建(Build)、测试(Test)、发布(ReLease)、部署(Deploy)、运维(Operate)、监控(Monitor)。其主要目的是促从开发与运维的有效合作，让开发人员更多的控制生产运营环境，以代码配置运行环境的基础设施，并通过尽可能自动化来实现更好，更快的软件发布更新过程。

本章不讨论devOPS的文化，扩展等内容。从技术角度看，关键点在于：代码定义的基础架构/持续交付和自动化/更好的团队协作。

代码定义的基础架构依赖于低层的云平台服务； 后两者，则取决于工具链以及协同的规范，并需要从乙方项目交付的视角来进行定义。

禁用列表

注意

下列软件禁止使用。后面8.1-8.8章节中列出的部分商业软件，不限制员工个人购买正版，使用破解版本引起的风险由员工个人承担！！！

推荐列表

推荐列表

8.1 规划(Plan)

8.1.1 售前与项目策划

售前规划阶段。主要是与用户方共同讨论，主要确定软件的开发目标及其可行性。其产出物肯定是一系列的Office文档。售前交流的文档按照产品级归集到 知识中心在新窗口打开。

规划阶段涉及到的一些绘图，有人用PowerPoint 画，有人用 Visio ，推荐使用 Visio 工具。

8.1.2 需求分析与设计

包括需求分析，系统架构设计，数据库设计，功能设计，UI设计等。

  • 分析设计工具 PowerDesinger

    需求分析与需求管理没有很好的工具，设计方面的一些CASE工具也不再受追捧。相对来说， PowerDesinger 还算是比较全面的，可以支持需求管理，UML建模，以及数据库设计。

  • 界面原型设计工具：Axure RP

    原型设计工具。虽然有墨刀等更为易用的工具，选择 Axure RP 的原因很简单：虽然入门门槛略高一点，但表达力强，扩展较为丰富。 因为 Axure RP 9 版本不再支持SVN团队协作，需要团队协作的项目，不要升级到 9 版本。也可以单独将原型文件作为二进制文件进行版本管理，只是这种模式不支持多人同时修改同一文件。

8.1.3 项目的管理与跟踪

  • 项目计划管理工具：Excel 熟悉的项目经理，可以用 project 工具进行项目计划的制定与发布。但是考虑到 project 的安装普及度不太高，大部分的人员对于 project 工具的使用也并不是很熟悉，甲方人员一般不使用Project ，因而，对外的计划发布（发布汇报给项目相关干系人），还是统一应当使用 excel 工具。计划的制定跟踪，可以用 Project 制定后转成 excel 发布，也可以用excel 直接制定，修订。
  • Microsoft Excel

但是，不应当用 excel 文档进行项目bug，特性的管理，而应当用私有GitLab在新窗口打开 的 issues 清单。

  • 项目工时、成本管理：WPM

按照公司规范的要填不，所有的项目人员投入，按规范填写WPM在新窗口打开工作汇报，统一管理成本与工时。

8.1.4 项目配置管理

  • 传统配置管理：SVN

    历史项目使用 SVN在新窗口打开 进行配置管理的，仍然沿用，新建项目统一迁到GitLab。

  • 代码/文档分库管理：GitLab

    项目经理（架构师）创建以信息系统或微服务组为单位的 group ，命名以 NameSpace以信息系统的系统英文简称为或者服务集合的英文简称为名称。如 metric.在group 下创建项目，项目以组件的构建成果物的名称为项目简称。 组名，项目名都不得包含特殊字付，中文字符。gitlab 中的 group 名称，与 harbor 镜像库中的 project 名称保持一致。

    软件类项目，为了构建部署方便来创建相应的项目。项目管理的文档（二进制office文档）单独创建一个项目。

8.2 编码(Code)

8.2.1 Java IDE集成开发环境

IDE 工具本来无所谓要统一的，只是为了在工程上，协助排查问题时，大家在一个工具上时，交流成本低一点。 Java IDE 统一到 IntelliJ IDEA在新窗口打开 且社区版也就够用了(缺少数据库连接，Perforce以及部分框架的支持，但对于SpringBoot的开发模式，完全够用)。

  • 一直在使用eclipse的老同事，也建议转成IDEA。另外，请不要使用 Myeclipse。

8.2.2 前端IDE集成开发环境

WebStorm在新窗口打开 确实是最好的前端开发工具，但不提供社区免费版本。 因此，推荐使用 VS Code在新窗口打开,搭配一些相应的扩展插件。

8.2.3 数据库客户端

  • 不同的数据库有不同的专门优化的客户端。但对于非专业DBA（开发人员）人员来说， 不必要这些专门客户端工具。 统一使用一个工具能支持多类数据库的即可。推荐使用 DBeaver在新窗口打开,用社区版即可。

  • 大数据开发相关的，应当命名用星环提供的 WaterDrop ,WaterDrop 是基于DBeaver 扩展开发的，也可以作为通用的数据库客户端使用。

  • 生产环境的数据库必须限定不允许开发人员直接连接而只能由指定的一两个人直连，并限制正常情况下为只读

  • 禁止使用 TOAD在新窗口打开 系列的所有工具,当然不限制员工个人购买正版。

8.2.4 其他辅助工具

Web 前后端开发人员都应当熟悉这两个工具：

8.3 构建(Build)

构建包括服务器端的自动构建与开发人员本地的构建测试工作。开发人员本地的构建测试工作，通常与IDE与相应语言的构建工具有关。服务器端构建则自动化一系列的构建、测试、部署工作。

8.3.1 Java 构建工具

  • 服务端开发的 Java 项目，构建和依赖管理工具还是用 Maven在新窗口打开 ，暂时不推荐用 Gradle。 java 代码的自动化构建也只维护Maven 的构建；当然 Andriod 的开发默认的构建工具为 Gradle 的，没有必要强制用 maven。

  • Maven 的默认镜像库，请设置为公司私服。在 setting.xml 文件中指定。

IDE 工具往往会自带一个 maven 运行时，建议不要用这个自带的而用本机安装的 maven ，并使用相同的配置文件以保证行为的一致性。

8.3.2 前端Web构建工具

  • 因为npm在新窗口打开是NodeJs在新窗口打开自带包管理器，对于一般的构建任务已经足够使用，直接使用 npm 进行依赖管理和构建。

  • npm 的 regiestry 库，请设置为公司私库，通过 npm config set registry 命令设置。

8.3.3 集成流水线

技术集成流水线几乎成了 DevOPS 的代名词。而在持续集成领域，Jenkins在新窗口打开 应当是被最广泛使用的。因为公司的 k8s 环境使用 Rancher在新窗口打开 进行管理，将通过Jenkins-构建在新窗口打开 项目，基于构建的成果发布到公司的Rancher平台。

切实因为环境限制，不能使用公司开发环境进行集成构建的，也建立项目组自行安装 Jenkins在新窗口打开 。并限定只能通过集成流水线的构建成果进行发布部署。

坚决反对直接往应用服务器上更新代码，put java class或相关资源进行更新的行为。服务器上运行的版本应当永远与配置库里的指定版本一致。

8.4 测试(Test)

因为各种限制 ，卓信的软件测试工作是一直比较落后的。另一方面，进行一般的数据库应用开发的自动化测试比较难落实。但为了保证程序质量，还是有必要不断推进自动化测试技术的应用。

8.4.1 单元测试

8.4.2 压力测试

压力测试的工具，使用Jmeter在新窗口打开。虽然易用性与功能方面不如 LoadRunner在新窗口打开完善，但应用场景与功能也足以支持一般的测试要求。

8.4.3 自动化测试

推荐专业测试人员学习与推广使用 Selenium在新窗口打开 自动化web测试工具。

8.4.4 BUG跟踪管理

BUG跟踪管理方向Jira 确实是非常强大的工具，但因为商业授权等原因，后续项目统一用GitLab在新窗口打开 的Issues(议题)功能。

推荐在代码提交时，通过在提交注释中写上 #id 的方式，与指定的 Issue 进行关联。

8.5 发布(ReLease)

在软件领域中，发布是指将Build的成品从不同的环境搬迁到生产环境，使其正式可用的过程。涉及到APP的分发还有专门的发布、审核，推广管理的事项； 不同的客户，对于发布更新的管理也有其不同的规范要求。

一般情况下，我们的项目没有复杂到需要使用专门的发布自动化工具的程度。因而不考虑专门的支撑工具平台。但是发布过程的管理要要求：

  • 每一次的发布，应当对应的有GIT 库的tag 或分支
  • 必须同步考虑周边服务的兼容性，对应的管理好服务的版本

8.6 部署(Deploy)

如前所述， 我们以后的软件部署，推荐都基于容器化的模式进行部署。

一般情况下，测试环境，通过Jenkins在新窗口打开的自动构建、发布过程自动更新测试环境的部署。生产环境的部署，通过给指定的 docker 镜像打tag （包括git 库的tag )，指定tag 版本更新到生产环境中。

8.7 运维(Operate)

卓信对于运维的技术方面还比较原始，实际上也没有碰到过要管理大量机器，大量应用实例的场景。因而很多的自动化运维手段与技术较少得到应用。 倒是可能通过写一部分 sh 脚本，python 脚本，结合 cron 定时调度，以处理一些重复性的事情比较常用。

8.7.1 服务器连接工具

8.7.2 自动化运维管理

对多台机器的自动化运维管理，首选 Ansible在新窗口打开

8.7.3 日志收集分析

生产环境下，日志收集分析可以使用ELK框架在新窗口打开,但这个在一般的小型项目集中，较少有部署。可以作为通用的服务推荐客户采用以作基础服务。

8.8 监控(Monitor)

应用的监控服务是非常重要的环节，包括服务的健康度监测、服务器资源监测等。一般涉及到专业工具，卓信较少参与。不同的客户有不同的监控手段。

在应用层面，K8s 对于服务的健康度检查是提供了较全面的支撑的，只要按规范配置相应的检查条件，K8s会自动检查服务的健康，必要时会自动重启pod，但是要做到进一步的异常通知，往往需要定制化的部署方案。

如果需要项目层面部署资源监控，那么统一用 Grafana在新窗口打开，这也是K8s 集群监控的默认解决方案。

上次更新:
编辑者: 李贤伟