简体   繁体   中英

How do you keep changes separate and isolated across multiple deployment environments in git?

At my workplace, we are attempting to design a workflow based around Git to handle our deployments and changes to the code.

We have a Java EE web application and 3 deployment environments (Test, QA and Production). We also have an instance of Jenkins CI to handle builds and deployments.

When changes are made to the application's code (in branches) we need to be able to pick and choose which ones get promoted to QA and Production. Some might get to QA and then never go to production.

We also need to be immune to accidentally including everyone else's code in your branch when promoting and merging.

The "promotion" of branches needs to also be automated - in such a way that an analyst would select the branch or changeset and then jenkins or some other script would do the actual merging and deployment. I see merge conflicts being an issue here...

How would you recommend setting up (a) Git repository(ies) to handle these requirements?

As I mention in " Code Promotion with Git ", don't forget that branches are not your only way to isolate development effort (like promotion across environment).

You have also git repositories themselves, and you can assign a git repo to a specific role (the "Test" repo, the "QA "repo", and so on)

Combined with Gitolite , you can protect those repositories against access by users who shouldn't directly push to a certain stage in development life-cycle.

Also combined with guarded commit , you can push to a test repo which would:

  • reject your commit if it doesn't pass compilation and / or certain unit tests
  • or accept it, and push it automatically to a QA repo for review.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM