首先介绍一下什么是 CODING DevOps，这里套用官网介绍
依托业界领先的敏捷项目管理理念与 DevOps 体系方法论，我们将这些优秀的理念与工具融入至产品中，打通了研发过程中的工具链孤岛及协作壁垒。在 CODING 平台中您可以实现需求提交到产品迭代，产品代码管理、自动化测试、持续集成，构建物管理、最终到应用持续部署的闭环研发工作流，覆盖敏捷开发全生命周期；助力您的团队提升研发效能，全面拥抱行业内领先的 IT 理念与文化。
说人话就是可以把软件开发流程的制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动在 CODING 上来实现
附官网链接，官方文档写的还算详细，这里就不浪费口舌了 https://help.coding.net/docs/start/new.html
这里套官网的话
云原生之路，始于众多事项的拆解与分配，「项目」是实践 CODING DevOps 的最小单位，你可以将它当做最基础的项目进度可视化协调工具，将合并请求关联至事项，分配缺陷至相关责任人。一个又一个的项目是组成团队有机体的最小细胞单位，短小精悍的项目单位却蕴含强大的可塑性。 潜心的匠人离不开趁手的工具，创造伟大产品的团队也需要精准高效的流水线车床，一个得心应手的事项管理机制正是团队迈向转型之路的起点。CODING 「项目协同」功能模块是协调各个事项的调度中心，我们为团队提供 Scrum 敏捷项目管理模式 和 经典项目管理模式 两种方案，团队可以根据管理偏好选择合适的模式。CODING 让所有协作发生在云端，通过合理的任务分配与处理机制实现无间协作，帮助团队攻克难关，高效生产，提高交付效率。
一句话解释：作为开发人员我们主要做编码工作，这里的需求、任务、迭代大多有项目经理、组长、产品来完成，我们都是自（被）愿（迫）接受
CODING 支持支持 Git / SVN 两种常见版本控制工具。支持本地仓库创建、 模板创建 导入外部仓库等三种方式
套官网说明
CODING 代码扫描能力可以通过分析代码仓库中的源代码，能够及时发现其中潜藏的代码缺陷、安全漏洞以及不规范代码；自动生成问题列表，附带修改建议，便于团队成员修复问题进而提升代码的稳定性；还可以通过对代码进行度量，统计出结构异常复杂的方法及重复代码供开发人员调整，进而提升代码的可维护性，提升团队效率。
一句话总结：发现代码中坏味道，提前发现问题，通过设置触发规则可以在推送代码时触发执行，对于一些积重难返的老项目，提供了增量扫描，减少遗留问题
附扫描概览截屏
接下来就是我们开发人员的重头戏了😁，附官网快速开始文档： https://help.coding.net/docs/ci/start.html，
第一步创建构建计划，选择自定义构建过程
第二步选择代码仓库，配置 Jenkinsfile 来源
这样就创建一个超级简单的构建计划。它会在我们推送代码到指定的仓库后执行，构建完后，打印自定义构建过程开始
那对于实际生产应用怎么配置嘞？如下是一个使用 maven 编译完毕后配合 Dockerfile 文件构建镜像推送到 CODING docker 制品库的构建计划
prepare：在编写构建计划前先要创建一个 docker 制品仓库，附官网说明： https://help.coding.net/docs/artifacts/intro.html
点击加号创建一个 docker 制品库
添加完成仓库地址后，点击确认即可创建一个 docker 制品库了
基础信息配置
选择项目中代码仓库
自动构建流程配置
通过 Jenkinsfile 配置
pipeline {
agent any
stages {
// 检出代码
stage('检出') {
steps {
checkout([$class: 'GitSCM',
branches: [[name: GIT_BUILD_REF]],
userRemoteConfigs: [[
url: GIT_REPO_URL,
credentialsId: CREDENTIALS_ID
]]])
}
}
// java 项目使用 mave 进行编译
stage('编译') {
// 官方提供的 maven 只有 3.5，jdk1.8 版本，如果需要使用 jdk11 可以按照文档 https://help.coding.net/docs/ci/ways.html 操作
steps {
sh 'mvn clean package'
}
}
// 编译完后将 jar 包通过代码中 Dokerfile 文件打包上传到 CODING Docker 制品库中
stage('构建镜像并推送到 CODING Docker 制品库') {
steps {
script {
docker.withRegistry(
"${CCI_CURRENT_WEB_PROTOCOL}://${CODING_DOCKER_REG_HOST}",
"${CODING_ARTIFACTS_CREDENTIALS_ID}"
) {
def dockerImage = docker.build("${CODING_DOCKER_IMAGE_NAME}:${DOCKER_IMAGE_VERSION}", "-f ${DOCKERFILE_PATH} ${DOCKER_BUILD_CONTEXT}")
dockerImage.push()
}
}
}
}
// 在上传到 CODING Docker 制品库后，通过 ssh 登陆服务器，使用命令行的方式进行镜像下载安装
stage('部署到远端服务') {
steps {
script {
// 定义变量
def remoteConfig = [:]
remoteConfig.name = "my-remote-server"
remoteConfig.host = "${REMOTE_HOST}"
remoteConfig.port = "${REMOTE_SSH_PORT}".toInteger()
remoteConfig.allowAnyHosts = true
withCredentials([
sshUserPrivateKey(
credentialsId: "${REMOTE_CRED}",
keyFileVariable: "privateKeyFilePath"
),
usernamePassword(
credentialsId: "${CODING_ARTIFACTS_CREDENTIALS_ID}",
usernameVariable: 'CODING_DOCKER_REG_USERNAME',
passwordVariable: 'CODING_DOCKER_REG_PASSWORD'
)
]) {
// SSH 登陆用户名
remoteConfig.user = "${REMOTE_USER_NAME}"
// SSH 私钥文件地址
remoteConfig.identityFile = privateKeyFilePath
// 请确保远端环境中有 Docker 环境
sshCommand(
remote: remoteConfig,
command: "docker login -u ${CODING_DOCKER_REG_USERNAME} -p ${CODING_DOCKER_REG_PASSWORD} ${CODING_DOCKER_REG_HOST}",
sudo: true,
)
// DOCKER_IMAGE_VERSION 中涉及到 GIT_LOCAL_BRANCH / GIT_TAG / GIT_COMMIT 的环境变量的使用
// 需要在本地完成拼接后，再传入到远端服务器中使用
DOCKER_IMAGE_URL = sh(
script: "echo ${CODING_DOCKER_REG_HOST}/${CODING_DOCKER_IMAGE_NAME}:${DOCKER_IMAGE_VERSION}",
returnStdout: true
)
sshCommand(
remote: remoteConfig,
command: "docker pull ${DOCKER_IMAGE_URL}",
sudo: true,
)
sshCommand(
remote: remoteConfig,
command: "docker rm -f ${IMAGE_NAME} | true",
sudo: true,
)
sshCommand(
remote: remoteConfig,
command: "docker run -d -p ${PORT}:${PORT} -e TZ=\"Asia/Shanghai\" -v /etc/localtime:/etc/localtime --name ${IMAGE_NAME} ${DOCKER_IMAGE_URL}",
sudo: true,
)
echo "部署成功，请到 http://${REMOTE_HOST}:${PORT} 预览效果"
}
}
}
}
}
environment {
CODING_DOCKER_REG_HOST = "${CCI_CURRENT_TEAM}-docker.pkg.${CCI_CURRENT_DOMAIN}"
CODING_DOCKER_IMAGE_NAME = "${PROJECT_NAME.toLowerCase()}/${DOCKER_REPO_NAME}/${IMAGE_NAME}"
}
}
Docker 配置如下：
# 该镜像需要依赖的基础镜像
FROM adoptopenjdk:8-jre-openj9
WORKDIR /root/workspace
# 将当前目录下的 jar 包复制到 docker 容器的 /目录下
ADD waynboot-admin-api/target/waynboot-admin-api-1.1.0.jar /opt/waynboot-mall/waynboot-admin-api-1.1.0.jar
# 运行过程中创建一个 mall-tiny-docker-file.jar 文件
RUN bash -c 'touch /opt/waynboot-mall/waynboot-admin-api-1.1.0.jar'
# 声明服务运行在 81 端口
EXPOSE 81
# 指定 docker 容器启动时运行 jar 包
ENTRYPOINT ["java", "-jar", "-Xms812m", "-Xmx812m", "-Xss512k", "/opt/waynboot-mall/waynboot-admin-api-1.1.0.jar"]
# 指定维护者的名字
MAINTAINER wayn111
添加构建计划的环境变量，在手动启动构建任务时，环境变量也将作为启动参数的默认值，在 Maven 项目中配置 maven 缓存可以大幅提高构建速度，附官网说明： https://help.coding.net/docs/ci/cache.html
这样就完成了一个生产级应用的构建计划了！😎怎么样对于一个开发人员来说是不是很简单😁
其实这一步就是测试人员的工作了，我也不是很懂就附官网说明把： https://help.coding.net/docs/test-management/start.html
其实 CODING 的功能远比我们想的强大，这里知识介绍了一部分，还有持续部署、OPEN API 、团队管理都没有做介绍了，但是通过以上六小节我们大致了解了 CODING DevOps 的工作流程，使用 CODING 来简化团队人员间的问题概览、责任人落实、协调沟通、构建部署等操作，至此我们就完成了 CODING DevOps 的使用初探啦！
这里推荐构建计划中使用到的 waynboot-mall 项目，是一套全部开源的微商城项目，包含一个运营后台、h5 商城和后台接口。 实现了一个商城所需的首页展示、商品分类、商品详情、sku 详情、商品搜索、加入购物车、结算下单、订单状态流转、商品评论等一系列功能。 技术上基于 Springboot2.0，整合了 Redis 、RabbitMQ 、ElasticSearch 等常用中间件， 贴近生产环境实际经验开发而来不断完善、优化、改进中。 在线地址： http://www.wayn.ltd
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.