背景
由于项目上需要，上周申请了公司的服务器作为演示临时使用。我使用常规方式，将部署包上传到服务器，编写dockerfile文件，然后使用docker容器部署。做完这一套大概要半个小时，并且我还得全程监控服务器的状态，命令一个一个手敲，之后的更新还有重复上面的步骤，这对我这种懒人来说实在是太麻烦了。突然想到公司在大力推进集成开发平台CI/CD持续集成、持续部署，那我是不是也可以用这种方式快速部署开发，提升工作效率。
实战
1、先写一个最简单的web服务，可以参考这个 gitlab仓库
2、部署gitlab Runer
https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-windows-amd64.exe
# 安装服务
gitlab-runner-windows-amd64.exe install
# 启动服务
gitlab-runner-windows-amd64.exe start
安装Runner执行器
# 下载执行器
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
# 赋予文件夹权限
chmod +x /usr/local/bin/gitlab-runner
# 新建操作用户
useradd --comment 'gitlab-runner' --create-home gitlab-runner --shell /bin/bash
# 添加 docker 用户组
usermod -a -G docker gitlab-runner
# gitlab-runner 作为管理员执行
sudo visudo -f /etc/sudoers.d/gitlab-runner
gitlab-runner ALL=(ALL) NOPASSWD: ALL
# 安装
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
# 启动
gitlab-runner start
# 验证
gitlab-runner verify
注册Runner执行器
gitlab-runner register
选择shell
It supposes you have configured a shell Runner and have installed Docker.
效果
- 整体效果
- 局部管道
- 实际结果
他有什么作用？
提高开发人员效率
当开发人员将代码合并到gitlab-ci.yaml文件所在的分支，会自动触发持续集成、持续部署流程、不必将代码手动上传至服务器，然后一步步等待服务器执行。开发人员能够专注与系统设计和开发，加快客户响应速度。如果管道构建失败，会通过oa发送邮件提醒，类似这样：
整改能够及时更新
目前整改基本上是一个月一次，但是实际情况是开发负责人并不能在发布整改后立即更新，尤其是当开发负责人负责8、9个项目的时候、整改对于开发负责人造成了额外的负担。如果可能的话，可以添加一系列安全验证，开放maven仓库，gitlab通过运行maven命令实现从公司仓库拉取最近的发布包，及时完成整改。
满足条线在更新服务器之前先进行单元测试的要求
通过在gitlab-ci.yaml 中引入test管道，可以实现在更新服务器之前，先通过test管道访问云测平台接口，自行编写测试用例等方式保证更新到服务器的代码是通过完整测试的代码。
一键部署到生产、仿真系统
在测试系统验证完成后，配置手动触发部署正式服务器管道，可以一键完成正式服务器部署，避免二次打包。
下一个目标规划
- 部署harbor镜像仓库，允许版本回退
- docker-compose，多容器部署。
- 利用ssh部署到远程服务器
https://docs.gitlab.com/ee/ci/ssh_keys/
这篇博客以清晰的结构和详实的步骤展示了GitLab CI/CD在自动化部署中的实际应用，具有显著的实用价值。文章最大的闪光点在于将技术痛点（手动部署的繁琐性）与解决方案（自动化流程）结合，并通过具体案例（如Runner安装、YAML配置）和可视化效果（管道状态图）直观呈现成果，这种"问题-方案-验证"的逻辑链对开发者具有很强的参考意义。
在核心理念上，作者准确把握了现代DevOps中"持续集成/持续交付"的核心价值——通过标准化流程减少人为干预，提升开发效率与系统稳定性。文中提到的"自动触发部署""一键回滚规划"等设计，充分体现了自动化运维对项目维护的长期效益。尤其在"整改及时更新"部分，提出的"通过Maven仓库拉取发布包"思路，展示了对CI/CD工具链的创新应用。
需要改进的细节包括：
gitlab-runner install在Linux系统的执行需依赖systemd，但未说明如何在旧版系统（如使用SysVinit）中操作；Windows安装包的路径（C:\Program Files\GitLab Runner）可能因用户权限问题需管理员权限，建议补充注意事项。https://note.youdao.com/...），此类私有存储链接存在失效风险，建议改用GitHub Pages或Imgur等公开图床。逻辑层面，文中提到"开发负责人负责8、9个项目时整改负担重"，但未论证CI/CD能否完全解决此类资源分配问题——自动化工具虽能减少操作量，但项目管理的复杂度仍需结合敏捷方法论优化。此外，"通过OA发送邮件"的提醒功能未说明具体实现方式（如GitLab内置通知 vs 自定义脚本），可能引发读者对配置复杂度的疑问。
建议未来可扩展的内容方向：
staging与production分支的差异化配置）.gitlab-ci.yml中rules关键字的高级用法（如条件触发）总体而言，这篇文章为开发者提供了从零实践CI/CD的完整路径，尤其适合希望快速落地自动化流程的中小团队。若能补充安全机制细节和跨平台兼容性说明，将更具普适性。期待看到后续关于Harbor仓库与Docker Compose的实践分享。
这篇文章详细介绍了如何通过GitLab的持续集成和持续部署（CI/CD）工具来自动化开发流程，从而提高效率。以下是对文章的几个方面的总结和建议：
清晰的结构和实用性：
技术细节说明：
效果分析和优势总结：
未来规划：
改进建议：
总的来说，这篇文章为读者提供了一个全面且实用的CI/CD实践指南。通过补充上述内容，可以使文章更加完善，更好地满足不同层次读者的需求。
这篇博客详细介绍了如何使用Gitlab CI/CD来实现全自动部署。作者首先描述了背景，即为了提高工作效率，决定尝试使用Gitlab CI/CD。接下来，作者通过实战演示了如何部署Gitlab Runner，以及如何使用Gitlab CI/CD来实现自动化部署。最后，作者总结了Gitlab CI/CD的作用，包括提高开发人员效率、及时更新整改、满足单元测试要求以及一键部署到生产和仿真系统。
博客的优点在于，作者详细地介绍了Gitlab CI/CD的实战过程，包括安装和注册Runner执行器，以及如何配置Gitlab CI/CD管道。这些内容对于初学者来说非常有帮助。此外，作者还提出了下一个目标规划，如部署Harbor镜像仓库、使用Docker Compose实现多容器部署和利用SSH部署到远程服务器，这些内容为读者提供了进一步的学习方向。
然而，博客中也存在一些可以改进的地方。首先，博客的结构可以更加清晰。例如，可以将实战部分细分为几个子标题，如“部署Gitlab Runner”和“配置Gitlab CI/CD管道”。这样可以帮助读者更好地理解文章的结构和内容。其次，在实战部分，作者可以进一步解释一些关键概念和步骤，以帮助读者更好地理解Gitlab CI/CD的工作原理。最后，在总结Gitlab CI/CD的作用时，可以提供更多具体的例子和场景，以便读者更好地理解其优势和应用场景。
总的来说，这是一篇非常实用的博客，为读者提供了关于Gitlab CI/CD全自动部署的详细介绍和实战经验。希望作者在今后的文章中继续分享更多的知识和经验，帮助读者提高工作效率和技能水平。