GitHub流的开发和生产环境 [英] Development and Production Environments with GitHub flow

问题描述

在工作中，我们现在正在使用GitHub，以及该GitHub流程.我对GitHub流的理解是有一个master分支和feature分支.与git flow不同，它没有开发分支.

At work, we're now using GitHub, and with that GitHub flow. My understanding of GitHub flow is that there is a master branch and feature branches. Unlike git flow, there is no develop branch.

这在我们已经完成的项目中效果很好，并且简化了事情.

This works quite well on projects that we've done, and simplifies things.

但是，对于我们的产品，我们拥有开发和生产环境.对于生产环境，我们使用 master 分支，而对于开发环境，我们不确定如何执行?

However, for our products, we have a development and production environment. For the production environment, we use the master branch, whereas for the development environment we're not sure how to do it?

我唯一能想到的想法是:

The only idea I can think of is:

1. 当分支与master合并时，使用GitHub操作重新部署master.
2. 当推送另一个分支时，请设置GitHub操作，以便将任何其他分支(主服务器除外)部署到此环境.

当前，对于需要开发环境的项目，我们基本上使用git flow(功能->开发->主).

Currently, for projects that require a development environment, we're essentially using git flow (features -> develop -> master).

您认为我的想法明智吗?如果不行，您会推荐什么?

Do you think my idea is sensible, and if not what would you recommend?

请澄清一下，我想问的是用 GitHub Flow 而不是 git flow 实施开发的最佳方法.

Just to clarify, I'm asking the best way to implement development with GitHub Flow and not git flow.

推荐答案

以我的经验，具有多个环境的GitHub Flow的工作原理如下.合并到母版不会自动部署到生产中.相反，与master合并将创建一个构建工件，该工件可以使用ChatOps工具在环境中进行升级.

In my experience, GitHub Flow with multiple environments works like this. Merging to master does not automatically deploy to production. Instead, merging to master creates a build artifact that is able to be promoted through environments using ChatOps tooling.

例如，推送到 master 会创建一个名为 my-service-47cbd6c 之类的构建工件，它是服务名和简短提交哈希的组合.这被推送到某种工件存储库中.然后可以使用诸如ChatOps样式斜杠命令之类的工具将工件部署到各种环境中，以触发部署.例如，该工具还可以进行检查以确保不跳过测试环境.最后，该工件被提升为生产.

For example, pushing to master creates a build artifact named something like my-service-47cbd6c, which is a combination of the service name and the short commit hash. This is pushed to an artifact repository of some kind. The artifact can then be deployed to various environments using tooling such as ChatOps style slash commands to trigger the deloy. This tooling could also have checks to make sure test environments are not skipped, for example. Finally, the artifact is promoted to production.

因此，对于您使用GitHub Actions的用例，我的建议是:

So for your use case with GitHub Actions, what I would suggest is this:

1. 推送到 master 会创建构建工件并将其自动部署到 development 环境中.
2. 开发中的测试
3. 通过使用斜杠命令部署到生产环境来提升工件. slash-command-dispatch 可以帮助您.

1. Pushing to master creates the build artifact and automatically deploys it to the development environment.
2. Test in development
3. Promote the artifact by deploying to production using a slash command. The action slash-command-dispatch would help you with this.

这篇关于GitHub流的开发和生产环境的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！