我们从GitHub迁移到GitLab

Also available in Portuguese

也提供葡萄牙语

Here at Mercos, we had already migrated in the past our source code hosting: in 2015 we left Beanstalk and went to GitHub. We were a team of approximately 7 developers and the migration was smooth. The reason behind it was basically to have more features: Pull Requests, integrations with other services, etc.

在Mercos ，过去我们已经迁移了源代码托管：2015年，我们离开了Beanstalk ，转到了GitHub 。 我们是一个由大约7个开发人员组成的团队，迁移非常顺利。 其背后的原因基本上是具有更多功能：拉取请求，与其他服务的集成等。

现状 (The status quo)

As years went by, we added some tools to our workflow: continuous integration, test coverage, static analysis, automatic dependency updates… But GitHub was still the same, stuck in time. We started to look at GitLab because it offered many of those tools already embedded, tools that GitHub only offered through third-party integrations that meant additional cost because they were other products.

随着时间的流逝，我们在工作流程中添加了一些工具：持续集成，测试覆盖率，静态分析，自动依赖项更新…但是GitHub仍然是一样的，但时间紧迫。 我们开始研究GitLab，因为它提供了许多已经嵌入的工具，而GitHub仅通过第三方集成提供了这些工具，这意味着它们是其他产品，因此意味着额外的成本。

Then Microsoft acquired GitHub and some announcements were made about technical advancements. We decided to wait a bit more and see if some of the new features could make it worth more than GitLab. Dependabot was something we had been using for some time, and the announcement that it was going to be free for GitHub users was very well received. GitHub Actions was the last straw we needed to convince ourselves that we better keep our code on GitHub.

然后， 微软收购了GitHub，并发布了一些有关技术进步的公告。 我们决定再等一会，看看是否有一些新功能可以使其比GitLab有价值。 Dependabot是我们使用了一段时间的东西，并且它对于GitHub用户将免费提供的声明受到了广泛好评。 GitHub Actions是我们说服自己最好将代码保存在GitHub上的最后一根稻草。

失望的 (The disappointment)

However, theory and practice aren’t always the same. We tried GitHub Actions and it was a bit disappointment. It’s a great alternative for OpenSource projects, because it’s completely free, but for Mercos it would become very expensive very quickly.

但是，理论和实践并不总是相同的。 我们尝试了GitHub Actions，这有点令人失望。 对于开源项目来说，它是一个很好的选择，因为它是完全免费的，但对于Mercos来说，它很快就会变得非常昂贵。

We tested using GitHub’s own infrastructure, charging by the minute. Each team has 10.000 minutes included for free in the plan. We depleted those minutes in a couple of days, and doing the math it would be too expensive to get all the minutes we needed. A continuous integration business model that encourages developers to test less doesn’t make sense to us.

我们使用GitHub自己的基础架构进行了测试，并按分钟计费。 每个团队有10.000分钟免费包含在计划中。 我们花了几天的时间来耗尽这些时间，而做数学运算来获取我们需要的所有时间将太昂贵了。 持续集成的商业模式，鼓励开发人员测试少没有意义给我们。

We went to the second test: Build our own infrastructure of GitHub Actions agents in AWS. It wasn’t easy: There’s no image available for GitHub Actions agents, and the best similar weighs many GB. Additionally, the registering and deregistering process in the agents is cumbersome, forcing us to consume GitHub’s API ourselves. Cost-wise, AWS machines are quite cheap, but the maintenance risk should something go wrong was too high for us.

我们进行了第二项测试：在AWS中构建自己的GitHub Actions代理基础架构。 这并不容易：GitHub Actions代理没有可用的映像，而最好的类似映像重达许多GB。 此外，代理中的注册和注销过程很麻烦，这迫使我们自己使用GitHub的API。 从成本角度来看，AWS机器相当便宜，但是如果出现问题，维护风险对于我们来说太高了。

为什么现在？ (Why now?)

The economic impact of 2020 events pushed us to make this change now. We had to make a big cut in cost. We evaluated again GitLab’s feature set and decided in favour of migrating. Here are the main points that made us change and what we’ve learned from it.

2020年事件的经济影响促使我们现在做出改变。 我们不得不大幅度削减成本。 我们再次评估了GitLab的功能，并决定迁移。 以下是使我们有所变化的主要方面以及从中汲取的教训。

决定的后台 (The decision’s backstage)

价钱 (Price)

GitHub was charging us $8 per user per month, while GitLab would charge us $4. We ended up choosing GitLab’s free plan, which gave it a somewhat unfair advantage over GitHub. Shortly after our migration, GitHub announced a pricing change that made their prices be very similar to GitLab’s. However, the free tier on GitHub doesn’t include basic feature like Wikis and even with similar pricing, GitLab’s offer is more advantageous.

GitHub的收费标准是每位用户每月8美元，而GitLab的收费标准是4美元。 我们最终选择了GitLab的免费计划，这给了它一个比GitHub更大的不公平优势。 在我们迁移之后不久， GitHub宣布了价格更改 ，这使得它们的价格与GitLab的价格非常相似。 但是，GitHub上的免费层不包括Wiki之类的基本功能，即使价格相近，GitLab的报价也更具优势。

稳定性 (Stability)

GitLab attracted a lot of attention a while ago because of an accidental data loss incident, which took around 24h to recover, partially, customers’ data. What surprised us was their seriousness and transparency while dealing with the situation: They live streamed debugging sessions showing the steps they were taking to fix the issue and then published an extensive post-mortem with the adopted measures to prevent it from happening again.

之前，由于一个意外的数据丢失事件，GitLab引起了很多关注，该事件大约需要24小时才能部分恢复客户的数据。 让我们感到惊讶的是，他们在处理情况时的认真性和透明性：他们现场直播了调试会话，展示了他们为解决该问题所采取的步骤，然后发布了广泛的事后调查，并采用了已采取的措施来防止再次发生。

GitHub hasn’t had an incident as serious, but over the years the feared pink unicorn was seen by many, making it impossible to access the web interface.

GitHub并没有发生那么严重的事件，但是多年来，许多人都看到了担心的粉红色独角兽，这使得无法访问Web界面。

In an eventual downtime, regardless of choosing GitLab or GitHub, the code stays backed up in all developers’ machines, and they can keep coding locally with no problems. Regarding issues and boards, we have a strong culture of communication that could temporarily adapt to email or messaging should the platform be unavailable for a few hours. And about the deploy: we took the measures of being able to manually execute deploy scripts in SREs’ machines should our CI be unavailable. This gives us confidence that we won’t be kept hostage by the code hosting platform we choose.

在最终的停机期间，无论选择GitLab还是GitHub，代码都将保留在所有开发人员的计算机中，并且他们可以毫无问题地在本地进行编码。 关于问题和董事会，我们有很强的沟通文化，如果平台几个小时不可用，它们会暂时适应电子邮件或消息传递。 关于部署：如果CI不可用，我们采取了措施，可以在SRE的计算机中手动执行部署脚本。 这使我们充满信心，我们不会被选择的代码托管平台束缚。

迁移者 (Migrator)

GitLab has an incredible migrator. It imports not only code, but all branches, issues, wiki pages, pull requests (transforming into merge requests), and etc. It’s just click and wait. It just works.

GitLab有一个令人难以置信的迁移器 。 它不仅导入代码，而且还导入所有分支，问题，Wiki页面，提取请求(转换为合并请求)等。只需单击并等待。 它就是有效的。

Tip: Use GitHub’s Archive Repository tool to make sure nobody will make any changes while the migration is happening.

提示 ：使用GitHub的Archive Repository工具来确保在迁移过程中没有人进行任何更改。

Tip 2: Add all users to GitLab beforehand, so the migrator can keep the same users linked to their commits, issues, comments and merge requests.

提示2 ：预先将所有用户添加到GitLab，以便迁移器可以将相同的用户链接到其提交，问题，评论和合并请求。

CI (CI)

GitLab CI is friendlier to our workflow, which is heavily based on Docker. Building our own infrastructure for GitHub Actions has been quite traumatic, full of workarounds. On the other hand, GitLab Ci has an included Helm Chart, so in a matter of minutes we had all the infrastructure running in AWS.

GitLab CI对我们的工作流更为友好，后者主要基于Docker。 为GitHub Actions构建我们自己的基础架构非常痛苦，充满了变通办法。 另一方面，GitLab Ci包含一个Helm Chart ，因此在几分钟之内，我们所有的基础架构都在AWS中运行。

Tip: Don’t use commands like docker or docker-compose in GitLab CI. Instead of docker build, use Kaniko with registry cache, it works really well. Instead of docker run or docker-compose run, use the image you just build with Kaniko as the CIimage in the next step.

提示 ：不要在GitLab CI中使用docker或docker-compose类的命令。 而不是docker docker build ，使用带有注册表缓存的 Kaniko ，它确实很好用。 在下一步中，请使用您刚刚使用Kaniko生成的image作为CI image ，而不是docker docker run或docker-compose run 。

Tip 2: By default GitLab CI runners only accept jobs that have specific tags, which frankly doesn’t make much sense for a default. In order to make them accept all jobs, add the following in the Helm Chart configuration:

提示2 ：默认情况下，GitLab CI运行程序仅接受带有特定标签的作业，坦率地说，默认设置没有太大意义。 为了使他们接受所有作业，请在Helm Chart配置中添加以下内容：

runners:
  runUntagged: true

Tip 3: GitLab’s documentation about running and scaling runners in Kubernetes isn’t very good. Instead of simply spinning up more Pods, you should increase a configuration called concurrent in the Helm Chart, letting GitLab Kubernetes Executor create Pods dynamically according to demand, and then your cluster-autoscaler (which should be already working in the cluster) will do its magic starting new cluster nodes when needed.

技巧3 ： GitLab关于Kubernetes中运行和扩展运行程序的文档不是很好。 您不应该简单地分解更多Pod，还应该在Helm Chart中增加一个称为concurrent的配置，让GitLab Kubernetes Executor根据需求动态创建Pod，然后您的cluster-autoscaler ( 应该已经在集群中工作了 )在需要时启动新群集节点的魔术。

问题与董事会 (Issues and Boards)

Given that we chose GitLab’s free plan, we weren’t able to create multiple Boards at the Group (Organization) level. So we adapted and started to use more boards in each repository.

鉴于我们选择了GitLab的免费计划，因此我们无法在组(组织)级别上创建多个董事会。 因此，我们进行了调整，并开始在每个存储库中使用更多的板。

Another point is that GitLab’s shows on Boards always all issues, with no option to add or remove issues from the board. Each stage on the board is identified by a label, so when we drag issues across board stages, we are effectively changing their labels.

另一点是，manbetx客户端打不开总是在董事会展示所有问题，没有选择添加或从董事会中删除问题。 董事会上的每个阶段均由标签标识，因此当我们在董事会各个阶段拖动问题时，我们正在有效地更改其标签。

Those limitations and linking of features caused us to actually be more organised with issues and labels, which is something nice, because in GitHub lots of issues ended up being forgotten about (we had even setup a stale-bot to try to mitigate this problem)

这些限制和功能的链接使我们实际上更加具有问题和标签的组织性，这很不错，因为在GitHub中最终遗忘了许多问题(我们甚至设置了一个过时的机器人来尝试缓解此问题)

依赖更新器 (Dependency updater)

As I mentioned in the beginning, we used Dependabot as our dependency updater in GitHub. While migrating to GitLab we discovered RenovateBot, which is even smarter (and works both with GitLab and GitHub).

正如我在一开始提到的，我们在GitHub中使用Dependabot作为我们的依赖项更新程序。 迁移到GitLab时，我们发现了RenovateBot ，它甚至更智能(并且可与GitLab和GitHub一起使用)。

It automatically identifies dependencies on multiple platforms (for instance: Python, Docker, GitLab-CI) and if any dependency isn’t fixed (pinned), it’ll firstly open an MR pinning that dependency and then after it’ll open others to update the versions.

它会自动识别在多个平台上的依赖关系(例如：Python，Docker，GitLab-CI)，如果任何依赖关系未得到固定(固定)，它将首先打开一个MR固定该依赖关系，然后将其打开以更新版本。

RenovateBot also identifies when some dependencies are from a single monorepo and groups their updates in the same MR, which is very interesting for JavaScript dependencies like babel. In the documentation there are lots of other configurations that can be made through renovate.json.

RenovateBot还可以识别某些依赖项何时来自单个monorepo，并将其更新分组在同一MR中，这对于像babel这样JavaScript依赖项非常有趣。 在文档中，可以通过renovate.json进行许多其他配置。

Tip: To see the bot’s execution logs, you have to login to the Dashboard. It’s a quite hidden link, but it helped us a lot to activate/deactivate repositories and also to find the reason why one or another dependency wasn’t being identified or updated.

提示 ：要查看机器人的执行日志，您必须登录到仪表板。 这是一个非常隐蔽的链接，但是它帮助我们激活/停用存储库，并找到了无法识别或更新一个或另一个依赖项的原因。

静态分析(Linter) (Static analysis (Linter))

GitLab offers an embedded Code Quality analysis that’s very flexible, based on CodeClimates’s open source technology. Apart from being free, it’s very easy to setup and to define styling rules for the code. Recently GitHub announced SuperLinter, but its execution consumes GitHub Actions minutes, which would make things even more expensive.

GitLab基于CodeClimates的开源技术，提供了非常灵活的嵌入式代码质量分析 。 除了免费之外，它还很容易设置和定义代码的样式规则。 GitHub最近发布了SuperLinter ，但其执行消耗了GitHub Actions分钟，这会使事情变得更加昂贵。

Tip: Leave the nomenclature and styling rules in the tools’ configuration files (for instance: .eslintrc, .pylintrc, etc), including the rules that determine which files ought to be ignored in the analysis. Leave in .codeclimate.yml only the configuration regarding which engines should be run. The analysis will be faster overall and you’re going to have a lot less headache when trying to debug some inconsistency.

提示 ：将命名规则和样式规则保留在工具的配置文件中(例如： .eslintrc ， .pylintrc等)，其中包括确定在分析中应忽略哪些文件的规则。 在.codeclimate.yml仅保留有关应运行哪些引擎的配置。 总体而言，分析将更快，并且在尝试调试某些不一致时，您会头疼得多。

最后评论和详细信息 (Last comments and details)

GitLab’s interface doesn’t auto-update (Hot Reload) when some new interaction happens in an issue or merge request. Having to always manually update the page to see new comments and etc has bothered us a little.

当问题或合并请求中发生一些新的交互时，GitLab的界面不会自动更新(热重载)。 必须始终手动更新页面以查看新评论等，这使我们有些困扰。

Mandatory Code Review in merge requests is a feature only available in paid plans. But given that we have a strong culture for code reviews and code quality in general at Mercos, everyone knows the process and values it, so we don’t have to enforce it in software.

合并请求中的强制性代码审查是一项仅在付费计划中可用的功能。 但是，考虑到我们通常在Mercos中拥有强大的代码审查和代码质量文化，每个人都知道该过程并重视它，因此我们不必在软件中强制执行它。

All our OpenSource repositories are still on GitHub, because all the limitations we found on GitHub don’t apply to OpenSource repositories, which have access to all resources for free.

我们所有的OpenSource存储库仍位于GitHub上，因为我们在GitHub上发现的所有限制都不适用于OpenSource存储库，后者可以免费访问所有资源。

下一步 (Next steps)

We still have to better explore GiLab’s integration with Kubernetes. The features that seem more promising to us are Review Apps and Deploy Boards.

我们仍然必须更好地探索GiLab与Kubernetes的集成 。 对我们来说，更有希望的功能是Review Apps和Deploy Boards 。

Review Apps is a feature of GitLab CI that creates, for each branch, an environment in which code from that branch gets deployed to and stays available for manual tests. We then configure for how long that environment should be active and after that time, it’ll delete it. It seems to be a very interesting feature for product people to test some small feature or fix before deploying to production, and also for dependency updates on the frontend that need some manual testing.

Review Apps是GitLab CI的一项功能，可为每个分支创建一个环境，在该环境中，该分支中的代码将部署到该环境中并可供手动测试使用。 然后，我们配置该环境应处于活动状态的时间，然后将其删除。 对于产品人员来说，在部署到生产之前测试一些小的功能或修复，以及对于需要一些手动测试的前端依赖更新，这似乎是一个非常有趣的功能。

Deploy Boards is another feature of GitLab CI that shows inside GitLab’s interface a Kubernetes deployment being made, Pod by Pod, so every developer can follow their deploy being applied live, with no need to access other tools. Additionally, we get log monitoring for free, and if we happen to have a Prometheus installation on the cluster, we also get application monitoring charts, automatically.

Deploy Boards是GitLab CI的另一个功能，它在GitLab的界面内显示了Pod by Pod进行的Kubernetes部署，因此每个开发人员都可以实时跟踪他们的部署，而无需访问其他工具。 此外，我们免费获得日志监视，并且如果在集群上碰巧安装了Prometheus，我们还将自动获得应用程序监视图表。

结论 (Conclusion)

The migration from GitHub to GitLab was quite smooth for Mercos. We learned that migrating source code hosting isn’t a big a monster as it could seem. We recommend GitLab for companies and teams that need to cut costs or that seek more embedded or native features in their source code hosting service.

对于Mercos，从GitHub到GitLab的迁移非常顺利。 我们了解到，迁移源代码托管似乎并不是一个大怪物。 对于需要削减成本或在源代码托管服务中寻求更多嵌入式或本机功能的公司和团队，我们建议使用GitLab。

We managed to keep all our workflow’s main features, that were previously separate services, in GitLab’s native features. We had to adapt regarding management of issues and boards, but that limitation is making us be more organised about it.

我们设法将工作流程的所有主要功能(以前是单独的服务)保留在GitLab的本机功能中。 我们必须对问题和董事会的管理进行调整，但是这种局限性使我们对此更加有条理。

Regarding innovation, Gitlab has very interesting features when integrated with a Kubernetes cluster, which can be very useful to those that have already started to enter this world of orchestration.

关于创新，当与Kubernetes集群集成时，Gitlab具有非常有趣的功能，这对于那些已经开始进入编排世界的人来说非常有用。

For OpenSource repositories, we conclude that the best alternative is still GitHub, because all features are completely free and the vast majority of OpenSource projects are already there, making it easier for the community to contribute with the project.

对于OpenSource存储库，我们得出结论，最好的选择仍然是GitHub，因为所有功能都是完全免费的，并且大多数OpenSource项目已经存在，这使得社区更容易为该项目做出贡献。

翻译自: https://medium.com/swlh/we-migrated-from-github-to-gitlab-41eec1d21355