与管道的持续集成

Question

我是一名 Android 开发人员，没有 CI/CD 管道经验，我们目前使用 GitLab 进行源代码控制。我正在处理的每个功能（我是目前唯一的 android 开发人员）我在一个单独的分支上做（分支 master 并在单独的分支上工作）。我们知道这不是最好的解决方案，但这就是我们现在的工作方式，我们希望改进它。

我们目前存在的一些问题：

1) 正如我之前提到的，每个功能目前都位于不同的分支上。当发布 testing/release 的版本时，我们只想使用一个 apk 而不是多个 apk，而且对于每个 apk，我们都需要增加版本号或更改应用程序名称，这在很长一段时间 运行。这个过程如何才能更充分、更有效？

2) 此解决方案也需要与 iOS 兼容。

有几种可能性，例如 Jenkins、Bamboo、Azure 管道和 GitLab CI。我不确定哪个是满足我们需求的更好选择。

谢谢。

Answer 1

有多种分支策略，也就是 git 工作流，经过很好的讨论和测试。这是 medium 上的一篇文章，详细讨论了它们 - https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf

这个流程依赖于两个分支

master — 这个分支包含生产代码。所有开发代码都在某个时间合并到主控中。

develop — 此分支包含预生产代码。当功能完成后，它们将合并到开发中。

我个人会推荐这种使用开发分支的策略 - 这样您的代码就会转到功能分支，然后开发，然后在开发上标记每个版本。

每个这样的版本都同步到主post-版本。您可以在媒体 post.

上阅读更多内容

希望对您有所帮助。

Answer 2

有许多策略可以满足您的要求。这取决于您的团队规模。

一种可能的主工作流 - 发布模式

1. 每个开发人员都在 master 分支上工作。在将本地更改推送到远程之前，他们需要 fetch 和 rebase 本地更改到 master 分支的最新提交，这意味着 push 必须是 fast-forward 推.

2. 当你需要一个发布版本时创建一个像release_v1.1.0这样的发布分支。开发人员修复了发布分支上的错误，并且 cherry-pick 所有错误修复也提交到 master 分支。

3. 开发人员还可以在 test-fix 生命周期中发布分支的同时继续在 master 分支上开发新功能。

产品的另一种出路——开发分离模式

1. developer 在他们自己的分支上工作，并保持 rebase 并将完成的更改合并到 develop 分支。同样，合并时需要 fast-forward 推送。

2. 使用master分支作为发布分支。从 develop 分支合并并在发布到产品环境时标记分支。

3. 记得 cherry-pick master 的修复也可以开发。

github 工作流程

使用 GitHub 中的 build-in 工作流程。