为什么选择GitLab CI / CD?

——使用GitLab开箱即用的CI / CD,您可以花费更少的时间来维护和创建更多的时间。

DevOps速度是企业的竞争优势。根据DORA,更频繁部署的公司在市场上表现更好。每个人都希望能够更好地完成工作并更频繁地进行部署,但随着组织的扩展,障碍不断涌现:

· 集成点太多 - 将CI / CD连接到DevOps工具链中的所有不同工具会让人感到困惑,并且不断向流程添加更多步骤和更多故障点。

· 脆弱的工具 - 我们花费更多的时间来维护和更新这些工具而不是实际创建新功能。

· 缓慢的现代化 - 我们希望利用微服务和云原生开发,但我们花了太多时间应对灾祸。

由于这些障碍带来了复杂的工作流程,缺乏管道可视性以及对流程的混淆。随着更多资源用于维护,总体拥有成本(TCO)不断增加,团队无法承受创新。随着组织的扩展,复杂程度只会变得更糟。

这听起来很累人,对吗?

当前的CI / CD工具

在GitLab里,我们非常喜欢透明度,因此我们将其作为我们的核心价值观之一。这也是我们在网站上列出所有其他DevOps工具的原因(是的,这是真的)。我们认为开放和直接的沟通是获得做出正确决策所需的反馈的最快方式。对于DevOps团队而言,正确的工具应该让事情变得更容易,但我们发现更多并不总是意味着更好。

高维护

将CI / CD工具与工具链的其余部分集成可能会变得复杂——定期管理和更新这些工具并不容易。许多团队依靠工具专家来保持一切顺利运行。

缺乏云原生兼容性

随着越来越多的组织希望利用微服务和云原生开发,他们将需要支持现代架构的CI / CD工具。对于某些CI / CD平台,团队仍需要额外的插件来连接Kubernetes或容器注册表。使用传统CI / CD工具的团队需要升级才能获得这些云原生功能。

工具链的复杂性

工具链有时与Rube Goldberg设备有太多共同之处。增加更多应用程序,更多平台和更多切换会增加复杂性,从而减慢团队的速度。再加上维护,插件和升级要求来管理这些单独的工具,生产力变得更加困难。

为什么团队喜欢GitLab CI / CD

CI / CD工具应该让工程师的管道更加可见,从而使工程师的生活更轻松,而不会给他们带来复杂的集成和插件维护。 GitLab CI / CD设计简单,因此团队可以立即开始使用它。

使用方便

GitLab使用任何开发人员都能理解的YAML配置,因此您可以更快地构建管道。

云原生CI / CD

凭借其内置的容器注册表和Kubernetes集成,GitLab支持云原生开发。

简单的架构

一个仅有一组权限的集成应用程序。

快速高效

使用自动扩展的runner,开发人员不再需要等待构建,并且VM会自动向上或向下旋转以更低的成本处理队列。

一切都在一个地方

GitLab CI / CD已内置于包含源代码管理,规划,监控等的同一应用程序中。

作为整个DevOps生命周期的单个应用程序,所有内容都在一个对话中,并且可以跨团队查看。使用GitLab开箱即用的CI / CD,您可以花费更少的时间来维护和创建更多的时间。它的CI / CD才有效。

我们邀请您自己探索GitLab CI / CD,看看为什么我们在Forrester CI Wave™中被评为#1。

原文链接:https://about.gitlab.com/2019/04/02/why-gitlab-ci-cd/