GitLab 9提供了子群组、部署面板和集成监控
jopen 8年前
<p style="text-align: center;"><a href="/misc/goto?guid=4958990238376480965" title="gitlab"><img alt="GitLab 9提供了子群组、部署面板和集成监控" src="https://simg.open-open.com/show/a2a15ac0cc9c90792e68b7b9cfd3a5e1.png" /></a></p> <p>英文原文： <a href="/misc/goto?guid=4959004942183509534">GitLab 9 Brings Subgroups, Deploy Boards, and Integrated Monitoring</a></p> <p>GitLab <a href="/misc/goto?guid=4959004942288769226">发布</a>了其软件开发协作平台的第九个版本（GitLab 9.0）。在所有的新特性中，最值得关注的是子群组（Subgroups）和集成性能监控。</p> <p><a href="/misc/goto?guid=4959004942381847466">子群组</a>在社区版和企业版中均可用，用于展示在很多企业中都可以看到的复杂层次结构。例如，对于一个给定的项目，你可以对后端团队、前端团队和设计团队各设立一个子群组，每个子群组可具有自身的代码库甚至是子群组。GitLab 支持多达 20 层子群组嵌套。群组成员继承了父群组的所有权限，可以作为特定群组关注的目标，实现了对通知的更细粒度的控制。</p> <p>在 GitLab CI/CD 管道中进一步集成了 <a href="/misc/goto?guid=4958987068788066856">Prometheus</a> 监控系统，这一特性可以改进团队的效率。GitLab 9.0 简化了对开发环境监控的使用，其中包括了 <a href="/misc/goto?guid=4959004942507885385">Review Apps</a>，一种绑定到特定分支的短生命周期的应用环境。当前，GitLab 可以监控 CPU 和内存的使用，并计划在未来支持评估代码合并所带来的性能影响，以及更多的度量指标。</p> <p>另一个重要新特性是部署面板。该特性只在高级企业版中提供，它允许用户查看 Kubernetes 在多台服务器上各个部署阶段的情况，无需访问 Kubernetes 就能轻易识别出所有可能发生的问题。</p> <p>GitLab 9.0 中还包括了更多的特性，其中一些特性只在企业版中提供，例如支持缺陷（Issue）记录的导出、数据库的负载均衡等，全部特性请参见官方文档。</p> <p><strong>InfoQ 采访了 GitLab 的 CEO 和联合创始人 Sid Sijbrandij。</strong></p> <p>GitLab 常被认为是一个基于 Web 的 Git 代码库管理器。现在它已发展成一个具有如此丰富特性的系统，不只是一个代码库管理器，它还包括了 CI/CD、缺陷管理、分析和在线交流等特性。你如何定义如今的 GitLab？特性间的平衡点在哪里？</p> <blockquote> <p>在过去数年中，我们一直致力于使现代软件开发技术对企业开发团队更为可用。我们已经从在单一平台上提供轻量级的缺陷追踪、版本控制和持续集成，发展成当前这种经过精炼的用户界面，连接了软件开发生命周期中的各个步骤。当前 GitLab 是首屈一指的自托管 Git 代码库管理解决方案，占据了约三分之二的市场份额。</p> <p>我们在 GitLab 9.0 中发布了一些新特性，对协作和审慎的所有权管理进行了改进，允许整个代码部署过程可见，具备了内建的应用监控。具体而言，这些特性包括子群组、部署面板和性能监控。</p> <p>我们在创建解决方案中考虑到所有人的需求，这就是 GitLab 的平衡点所在。我们所做的所有事情都是为了进一步简化软件的开发、改进每个用户的访问、增进开发过程各个阶段的一体化。</p> </blockquote> <p>数周前，GitLab 发生了一次<a href="/misc/goto?guid=4959004942605004440">重大事故</a>。事故导致了 GitLab 的服务长时间不可用，以及数据的丢失。相关企业和受影响的客户是如何从这次事故中恢复的？你们在事故发生时提出了一个对恢复过程的改进，进展如何？最后一点，事故给出了哪些经验教训？</p> <blockquote> <p>在发生故障的第一时间，我们就开始将一个纠正现状的过程部署到位。我们依然积极致力于从整体上改进 <a href="/misc/goto?guid=4959004942705472950">GitLab.com</a> 的架构，以确保这类故障不再发生。具体而言，正如在<a href="/misc/goto?guid=4959004942794273442">博客帖子中所介绍的</a>，我们正在实现一个故障恢复的解决方案，改进我们的代码库滥用上报及响应机制。GitLab 的进展情况是公开的，大家可以从我们的缺陷追踪系统（Issue Tracker）上直接查看我们的进展情况。</p> <p>我们从这次故障中汲取了一些非常有价值的经验教训。首先，我们知道最为重要的是需要对架构投入时间、资金和能量。其次，发生故障时应对社区保持开放和交流的态度。透明度是我们作为一个公司的核心价值之一，既然故障已经发生，那么就应该在社区中发出告警，并在恢复过程中保持信息的实时更新，这一点是十分重要的。最后一点，我们是这一社区的一份子，这次事故中我们收到了成百的鼓励消息，他们不仅来自于我们的用户、合作者，甚至还有竞争者，这使得问题更为明晰。对此我们会时刻铭记于心。</p> <p>这次事故清除了大约 5000 个项目、5000 个评论和 700 个新用户账户的元数据，但是相关的代码和文件等并未受到影响，我们正与受影响的用户共同努力，尽可能地恢复他们对账号和数据的访问。GitLab 企业客户、GitHost 客户和自托管 GitLab 社区版客户没有丢失任何数据，也没有受到事故的影响。</p> </blockquote> <p>能介绍一下 GitLab 未来数月的路线图吗？</p> <blockquote> <p>我们已规划在数月内推出一些新特性和功能，GitLab 9.0 仅是一个开始。我们的目标是成为最受欢迎的公共代码库 SaaS 解决方案。GitLab 9.1 将于今年的 4 月 22 日发布，其中包括新的服务桌面功能、零停机迁移和缺陷面板更新等新特性。这将是我们第 65 个月度连续发布产品，我们对此速度引以为豪，在业界无人可并驾齐驱。</p> </blockquote> <p>来自: <a href="/misc/goto?guid=4959004942886358058" id="link_source2">InfoQ</a></p>