首页 文章

如何使用TeamCity和Octopus完成此分支和部署策略

提问于
浏览
0

我一直在研究并试图找出最佳的分支和部署策略来完成下面的要求 . 也许我错过了一些东西,但它似乎比看起来更复杂 . 理想情况下,我们只有一个永久分支“master”,它可以标记特定的提交以将版本标记为 生产环境 .

我们当前的战略基于Git Flow,并拥有永久分支机构的“主人”(仅发布到 生产环境 )和“开发” . 使用多个永久分支模型复杂化的主要问题是将“相同的构建”从登台环境“提升”到 生产环境 的概念 . 目前,这需要在一个单独的源代码分支中完成(部署到staging来自'develop',部署到prod来自'master') .

Tools: Git(VSTS),TeamCity,Octopus Deploy

Requirements (feature and hotfix lifecycles):

  • 所有代码都通过拉取请求进行审核(通过分支政策强制执行)

  • 所有代码都部署到临时环境进行测试

  • 我们可以快速返回之前部署的任何代码快照

  • 如果测试成功,那么相同的构建可以从我们的暂存环境“提升”到 生产环境 (无需再次构建)

在作为单个版本推出 生产环境 之前,功能会随着时间的推移而累积 . 修补程序必须能够通过而不会陷入下一个常规版本的“全有或全无” .

我喜欢有一个带标签的永久分支的想法(re:master / develop split是多余的,http://endoflineblog.com/gitflow-considered-harmful),但是有额外的永久分支可能更好地促进部署到Octopus的不同生命周期/版本(功能和修补程序) .

我一直在努力解决这个问题的最佳方法,我可能会让事情变得复杂 . 任何反馈都表示赞赏 .

1 回答

  • 1

    看起来你有很多问题而且它们相当广泛...我会在你的每个要求中添加一些评论作为对话启动者,但这整个帖子可能会被版主阻止,因为它绝对不是问题的风格SO是为了 .


    所有代码都通过拉取请求进行审核(通过分支政策强制执行)

    我没有看过很多年的VSTS,但我希望他们已经支持分支策略和拉取请求,所以不确定除了配置存储库中的设置之外,还有什么需要 .

    如果VSTS不支持,您可以考虑转移到一个工具,例如, BitBucket,_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    所有代码都部署到临时环境进行测试

    您可以通过设置lifecycles in Octopus Deploy来实现这一目标,以确保部署/促销遵循您想要的顺序 .

    我们可以快速返回之前部署的任何代码快照

    您已经拥有源代码控制,因此您现在所需要的只是从环境中部署的代码到Octopus Deploy中的部署版本,TeamCity中的构建作业,源代码管理中的分支和精确提交的可跟踪性 .

    为了达到这个目的,你可以做一些事情:

    • 定义适合您的版本控制方案 . 我喜欢使用语义版本控制 . "Major"和"Minor"版本由开发人员定义,"Patch"是TeamCity中自动递增的数字(%build.number%) . 每个 git push 构建代码并生成一个唯一的构建版本(%major% . %minor% . %build.number%)

    • 作为TeamCity中构建步骤的一部分,在编译代码之前,请确保使用每个构建分配的 the version number (来自源代码管理的 commit hashand the branch name )修补源文件 . 例如如果您使用的是.NET,请确保使用该版本更新所有AssemblyInfo.cs文件,以便将版本嵌入到二进制文件中 . 这允许任何人查询查看二进制文件属性的版本,还允许您在应用程序本身上显示应用程序版本(例如状态栏,页脚, Headers ,关于框等)

    • 让TeamCity使用每个构建的版本号标记源代码控制,以便快速查看源代码管理历史记录 . 您可能只想为主分支执行此操作,尽管这是您关心的内容 .

    • 使用部署版本号和环境名称将Octopus标记为源代码管理,以便快速完成看(从您的源代码管理中)部署在哪里 .

    第一步和第二步是最重要的,真的 . 3和4是很好的 . 大多数情况下,您只需在环境中打开应用程序,检查"About"中的提交哈希值,并对该提交哈希值执行 git checkout ...

    如果测试成功,那么可以从我们的暂存环境“升级”到 生产环境 (不需要再次构建)

    同样,Octopus Deploy lifecycles,并确保在应用程序的配置文件中定义了每个环境中的任何不同内容,该文件在Octopus部署期间使用environment-specific variables进行更新 .

    在分支工作流方面,最后一个要求使得必须在部署生命周期开始之前将更改合并到 master (或任何"production"分支) .

相关问题