从 13 年开始使用 GitLab 到现在，看着这款软件的快速进化，还是很感慨的。
随着 GitLab v13 的发布，几乎任何一家公司都能快速拥有和头部大公司一样轻松获取生产中的具有规模化的 DevOps 部署能力、高度透明的应用管理能力、以及快速的发布迭代能力。
下面来简单梳理下 GitLab 的 CI / CD 功能发展历程吧。
笨重的大象准备跳舞
2015年4月末，一篇带有“感叹号”的博客由官方发出《GitLab on Raspberry Pi 2!》，一直被诟病吃 CPU、内存的 GitLab 可以跑在树莓派上了，随后官方开启了高频软件更新迭代。
第一阶段：开始支持 CI 功能，使用自动化方式提升效率
在同年的6月末，发布了极具战略意义的重要版本 GitLab v7.12，这个版本支持了 SAML 认证，Merge Request 准许功能（类似 GitHub 上的手动允许合并功能），以及最重要的一点：对原本的 CI 功能进行了重构，支持了 .gitlab-ci.yml 使用 CI 配置文件、内置了 WebHook 功能。随后，官方收到了不少反馈，于是在同年9月的时候，发布了拥有新界面的 GitLab v8.0 ，并默认集成了 CI 功能。
熟悉 CI 的同学都知道，有无独立的 CI 配置文件，可以说是 “infrastructure as code” 的开始，早在 2010 年创立的 Travis CI 便让使用 GitHub 的用户体验到了仅需要填写声明式配置，其余的事情都交给 CI 机器人来完成的快感。
但是确实不是所有项目、内容都适合公网部署、使用公开服务，出于各种原因，我们还是需要一款能够在内部网络环境运行的类似服务。随着这家大型商业、私有化部署软件开始支持这个事情，CI 技术普惠的浪潮开启了。专注于做 CI 功能的 开源软件 Drone 虽然比 GitLab CI 推出时间早一年，但是此刻 GitLab 已经有了多家大型公司使用，以及有更多的公司开始尝试将老系统迁移到它上面，比如当时我所在的公司淘宝网（阿里巴巴集团）。
再随后，在 2016 年3月末，官方推出了支持自动扩容的 GitLab Runner v1.1 版本，一年之后，在 2017 年 3月，带来了支持子分组和具备更直观的项目部署面板的 GitLab v9.0。至此，任何一家公司都能够在数小时至几分钟内使用传统安装或者容器部署的方式快速体验完整的 CI 全流程。
第二阶段：拥抱K8S生态，完善 CD 功能，完成开发全生命周期布局
在 2017 年下半年，9月22日，GitLab 官方推出了 v10.0 ，进一步完善了群组 Issue 面板，并带来了全新的 Auto DevOps 功能，开始将发重点由 CI 朝 CD 发展。到了 2018 年的中旬 6月22日，因为 Kubernetes 如日中天，GitLab v11.0 版本中，官方进一步将 Kubernetes 与 Auto DevOps 进行集成，并添加了 Web IDE 、安全扫描、许可证扫描。
至此，如果你选择使用 GitLab “服务全家桶”，那么 Auto DevOps 将覆盖你的生产全生命周期：提交代码之后，构建、测试、质量扫描、安全扫描、许可证扫描、应用构建、应用打包、性能测试、自动化部署、应用监控。当然还有自 8.0 时代就开始发力迭代的基于项目规划、讨论、问题等知识管理功能。
第三阶段：完善云时代的开发体验
时间转到2019年的6月22日，v12.0 推出了，其中和 CI 最重要的功能是四年前推出的 .gitlab-ci.yml 配置文件可以通过 extends 方式来进行拓展和模块化，意味着多个项目中重复的 CI 配置内容可以减少，用户不用费尽心思将一些共有的内容往 CI 调用的脚本、服务中塞了，以及支持了“顺序合并火车”，对于容器仓库的体验进行了优化、提供了项目依赖清单，增强了 Web IDE ，用户可以在 Web 浏览器中直接访问项目开发环境，而不需要进行本地配置，甚至基于 GitLab 快速使用 Jupyter Book。
到了去年 2020 年 5月 的时候，GitLab v13.0 到来，官方进一步优化了在线编辑器和 .gitlab-ci.yml 配置文件的书写体验，以及添加了新的 CI 触发方式，可以在看板中根据作者或者分支进行筛选和触发构建。同时发布了 GitLab Runner v13.0，并且支持了从 .env 文件中传递环境变量，进一步减少了多环境下 CI 配置文件的膨胀问题，以及将环境变量能够在仓库中集中管理，避免了应用核心信息分散在各种仓库分组的系统配置中。基于 GitLab 管理的项目甚至可以直接部署至 ECS 中。
未来？
未来的 GitLab 也一定会继续着力生产开发全生命周期的体验和效率的改进，让开发协作变的高效、愉快，比如更高效易用的协作看板、事务追踪系统、更好用的知识管理、文档管理系统。
随着近两年硬件 / 网络的发展，消费硬件也好，云生态也好，会带来软件的“报复性”发展，相信假以时日，随着 Web IDE 的进一步强大和完善，对于开发人员设备性能的需求可以进一步降低，使用轻薄的上网本甚至 iPad 来编码也在部分重型项目中成为了可能，后续我将单独写一篇文章，聊聊我在过去的实践和遇到的问题。
使用 GitLab 的意义
在聊意义前，首先要明确你和你的团队是否是它的受众。如果你们有现成的研发过程管理系统、CI 系统、CD 系统、监控系统等；或者如果你是一个独立开发者，一个“独行侠”，不希望基于它完成产品研发工作事务协作，只是用它完成代码存储，那么你多数会觉得它功能复杂、吃资源。
但是对于小到几个人，大到几万研发的公司来说，GitLab 都是一个不错的选择。甚至有一些我们都听过的，基于 GitLab 修改而成的开放代码托管平台，也证明了这款软件的底子足够优秀。
对于需要它的产品开发团队而言，围绕或者基于 GitLab 等开源软件进行协作和生产部署、产品设计，事务天生“透明”，工作会变得越来越有序和轻松。而它之于公司，数字资产的安全性得到了保障、产品质量得到了“底层”提升，人效成本的减少，相比较不用、或者滥用基础设施软件的好处不言而喻。
是否有小而美的选择
前文提到，GitLab 对于“个人”或者不希望重度使用它的公司来说，有一些“重”了。那么有没有轻量的使用方式呢？或者有没有替换方案呢？
显然是有的，下一篇内容，我将展开聊聊，如何“科学的”使用老版本的 GitLab 以及它的优秀竞争对手 Gitea + Drone 。
最后
如果你对 GitLab 的使用感兴趣，可以关注我之前写过的一些文章，里面包含了如何升级、维护，以及各种使用小细节。
– EOF