Mixing
GIT Multi-tier configuration for environments: [DEV -> QA -> PROD] [closed]
I have the following hierarchy like multiple developers push their code and test on their DEV server, once that seems to be fine, it should go for QA's Verification on QA server, and once QA approves then it should go to PROD server which will be available for customers.
e
The code needs to be maintained under GIT.
I would like to know, what is the best practice on how we can configure such structure of CODE flow under SDLC.
Thanks.
git
asked Jan 1 at 19:05
Sharad SoniSharad Soni
5310
closed as primarily opinion-based by jonrsharpe, Dan Farrell, René Höhle, david, Roman Pokrovskij Jan 2 at 19:27
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
I have the following hierarchy like multiple developers push their code and test on their DEV server, once that seems to be fine, it should go for QA's Verification on QA server, and once QA approves then it should go to PROD server which will be available for customers.
e
The code needs to be maintained under GIT.
I would like to know, what is the best practice on how we can configure such structure of CODE flow under SDLC.
Thanks.
git
asked Jan 1 at 19:05
Sharad SoniSharad Soni
5310
closed as primarily opinion-based by jonrsharpe, Dan Farrell, René Höhle, david, Roman Pokrovskij Jan 2 at 19:27
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
Great question, but not a good fit for stack overflow.
– Dan Farrell
Jan 1 at 19:41
add a comment |
I have the following hierarchy like multiple developers push their code and test on their DEV server, once that seems to be fine, it should go for QA's Verification on QA server, and once QA approves then it should go to PROD server which will be available for customers.
e
The code needs to be maintained under GIT.
I would like to know, what is the best practice on how we can configure such structure of CODE flow under SDLC.
Thanks.
git
asked Jan 1 at 19:05
Sharad SoniSharad Soni
5310
I have the following hierarchy like multiple developers push their code and test on their DEV server, once that seems to be fine, it should go for QA's Verification on QA server, and once QA approves then it should go to PROD server which will be available for customers.
e
The code needs to be maintained under GIT.
I would like to know, what is the best practice on how we can configure such structure of CODE flow under SDLC.
Thanks.
git
git
asked Jan 1 at 19:05
Sharad SoniSharad Soni
5310
asked Jan 1 at 19:05
Sharad SoniSharad Soni
5310
asked Jan 1 at 19:05
Sharad SoniSharad Soni
5310
asked Jan 1 at 19:05
Sharad SoniSharad Soni
5310
asked Jan 1 at 19:05
Sharad SoniSharad Soni
5310
5310
closed as primarily opinion-based by jonrsharpe, Dan Farrell, René Höhle, david, Roman Pokrovskij Jan 2 at 19:27
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by jonrsharpe, Dan Farrell, René Höhle, david, Roman Pokrovskij Jan 2 at 19:27
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
Great question, but not a good fit for stack overflow.
– Dan Farrell
Jan 1 at 19:41
add a comment |
1
Great question, but not a good fit for stack overflow.
– Dan Farrell
Jan 1 at 19:41
1
1
Great question, but not a good fit for stack overflow.
– Dan Farrell
Jan 1 at 19:41
Great question, but not a good fit for stack overflow.
– Dan Farrell
Jan 1 at 19:41
add a comment |
1 Answer
1
active
oldest
votes
Git is not a release manager. You can force it to be one, but it won't work well.
Instead, here's the principles of a simple continuous release/delivery workflow.
There is one long lived branch, master.
Even in git, maintaining long lived branches is complicated and best avoided. You have one branch both to develop from and to deploy: master.
master is at all times ready for release.
Nothing goes into master that isn't ready for release. This gives developers a stable platform from which to develop on, QA a stable platform for testing, and you can deploy the latest complete features with confidence at any time.
All development happens in feature branches.
You keep master at high quality by doing all development in branches off master. This allows each task to be isolated from the others, and developers are free to experiment without breaking the build.
Put another way, your development, integration, testing, and acceptance phases all happen in feature branches. Maintenance also happens as discrete feature branches.
Feature branches are well defined and short lived.
Keeping with the idea that long lived branches are painful, feature branches should be associated with one ticket, issue, or story. The purpose of the branch should be well defined and it should be clear when it's done. Once it's done, the branch is deleted to ensure it is not reused and to avoid branch clutter.
Your analysis and design phases must result in implementation tasks which can be chopped up into discrete tasks which can be done in a short lived feature branch. This requires some practice to learn how to do.
Use git merge --no-ff to ensure the branch is preserved in the topology of the commit history. Use the merge commit message to record any important information about the branch for future archeology such as references to the issue it is solving.
A - B ------------- M - N - O [master]
/
C - D - E - F
These are known as "feature bubbles". They make it clear that commits C, D, E, and F were done as a commit and we should look at M for information about the branch. Use git log --graph --decorate to get such a view, or any number of Git history visualizers.
Feature branches are rebased onto master.
To avoid feature branches falling out of date, they are habitually brought up to date with master. No feature is considered complete until it has been brought up to date with master, conflicts resolved, and all tests passing.
To avoid excessive bookkeeping merges, use git rebase master to keep history clean. Here's an example of what an out of date feature branch looks like. The F - G "bubble" is a completed feature branch.
F - G
/
A - B ----- H [master]
C - D - E [feature]
And then after rebasing it.
git checkout feature
git rebase master
F - G
/
A - B ----- H [master]
C1 - D1 - E1 [feature]
Feature branches must pass CI and QA before merging.
This guarantees that master is at all times ready for release. Since feature branches are kept up to date with master, QA on the branch also QA's master after the merge.
Deploy master to staging and production.
This is what it's all leading to. There are no staging and production branches. At any time you can deploy master to staging. Once you're satisfied it's ready, you can deploy that commit to production. If you like you can also git tag staging or git tag production the commit which is deployed. This is the workflow used by things such as Heroku Pipelines.
What about hot patches?
Make a temporary branch off the production tag, git branch hot-patch production. Commit the hot patches to that branch. Deploy that branch.
Once the emergency is over, and as quickly as possible, redo the hot patches as a normal feature branch and normal deployment process. You can use git cherry-pick or git rebase to get the hot patch changes on top of master. Once the properly done fix is deployed, delete the hot patch branch.
answered Jan 1 at 21:21
SchwernSchwern
90.7k17103237
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Git is not a release manager. You can force it to be one, but it won't work well.
Instead, here's the principles of a simple continuous release/delivery workflow.
There is one long lived branch, master.
Even in git, maintaining long lived branches is complicated and best avoided. You have one branch both to develop from and to deploy: master.
master is at all times ready for release.
Nothing goes into master that isn't ready for release. This gives developers a stable platform from which to develop on, QA a stable platform for testing, and you can deploy the latest complete features with confidence at any time.
All development happens in feature branches.
You keep master at high quality by doing all development in branches off master. This allows each task to be isolated from the others, and developers are free to experiment without breaking the build.
Put another way, your development, integration, testing, and acceptance phases all happen in feature branches. Maintenance also happens as discrete feature branches.
Feature branches are well defined and short lived.
Keeping with the idea that long lived branches are painful, feature branches should be associated with one ticket, issue, or story. The purpose of the branch should be well defined and it should be clear when it's done. Once it's done, the branch is deleted to ensure it is not reused and to avoid branch clutter.
Your analysis and design phases must result in implementation tasks which can be chopped up into discrete tasks which can be done in a short lived feature branch. This requires some practice to learn how to do.
Use git merge --no-ff to ensure the branch is preserved in the topology of the commit history. Use the merge commit message to record any important information about the branch for future archeology such as references to the issue it is solving.
A - B ------------- M - N - O [master]
/
C - D - E - F
These are known as "feature bubbles". They make it clear that commits C, D, E, and F were done as a commit and we should look at M for information about the branch. Use git log --graph --decorate to get such a view, or any number of Git history visualizers.
Feature branches are rebased onto master.
To avoid feature branches falling out of date, they are habitually brought up to date with master. No feature is considered complete until it has been brought up to date with master, conflicts resolved, and all tests passing.
To avoid excessive bookkeeping merges, use git rebase master to keep history clean. Here's an example of what an out of date feature branch looks like. The F - G "bubble" is a completed feature branch.
F - G
/
A - B ----- H [master]
C - D - E [feature]
And then after rebasing it.
git checkout feature
git rebase master
F - G
/
A - B ----- H [master]
C1 - D1 - E1 [feature]
Feature branches must pass CI and QA before merging.
This guarantees that master is at all times ready for release. Since feature branches are kept up to date with master, QA on the branch also QA's master after the merge.
Deploy master to staging and production.
This is what it's all leading to. There are no staging and production branches. At any time you can deploy master to staging. Once you're satisfied it's ready, you can deploy that commit to production. If you like you can also git tag staging or git tag production the commit which is deployed. This is the workflow used by things such as Heroku Pipelines.
What about hot patches?
Make a temporary branch off the production tag, git branch hot-patch production. Commit the hot patches to that branch. Deploy that branch.
Once the emergency is over, and as quickly as possible, redo the hot patches as a normal feature branch and normal deployment process. You can use git cherry-pick or git rebase to get the hot patch changes on top of master. Once the properly done fix is deployed, delete the hot patch branch.
answered Jan 1 at 21:21
SchwernSchwern
90.7k17103237
add a comment |
Git is not a release manager. You can force it to be one, but it won't work well.
Instead, here's the principles of a simple continuous release/delivery workflow.
There is one long lived branch, master.
Even in git, maintaining long lived branches is complicated and best avoided. You have one branch both to develop from and to deploy: master.
master is at all times ready for release.
Nothing goes into master that isn't ready for release. This gives developers a stable platform from which to develop on, QA a stable platform for testing, and you can deploy the latest complete features with confidence at any time.
All development happens in feature branches.
You keep master at high quality by doing all development in branches off master. This allows each task to be isolated from the others, and developers are free to experiment without breaking the build.
Put another way, your development, integration, testing, and acceptance phases all happen in feature branches. Maintenance also happens as discrete feature branches.
Feature branches are well defined and short lived.
Keeping with the idea that long lived branches are painful, feature branches should be associated with one ticket, issue, or story. The purpose of the branch should be well defined and it should be clear when it's done. Once it's done, the branch is deleted to ensure it is not reused and to avoid branch clutter.
Your analysis and design phases must result in implementation tasks which can be chopped up into discrete tasks which can be done in a short lived feature branch. This requires some practice to learn how to do.
Use git merge --no-ff to ensure the branch is preserved in the topology of the commit history. Use the merge commit message to record any important information about the branch for future archeology such as references to the issue it is solving.
A - B ------------- M - N - O [master]
/
C - D - E - F
These are known as "feature bubbles". They make it clear that commits C, D, E, and F were done as a commit and we should look at M for information about the branch. Use git log --graph --decorate to get such a view, or any number of Git history visualizers.
Feature branches are rebased onto master.
To avoid feature branches falling out of date, they are habitually brought up to date with master. No feature is considered complete until it has been brought up to date with master, conflicts resolved, and all tests passing.
To avoid excessive bookkeeping merges, use git rebase master to keep history clean. Here's an example of what an out of date feature branch looks like. The F - G "bubble" is a completed feature branch.
F - G
/
A - B ----- H [master]
C - D - E [feature]
And then after rebasing it.
git checkout feature
git rebase master
F - G
/
A - B ----- H [master]
C1 - D1 - E1 [feature]
Feature branches must pass CI and QA before merging.
This guarantees that master is at all times ready for release. Since feature branches are kept up to date with master, QA on the branch also QA's master after the merge.
Deploy master to staging and production.
This is what it's all leading to. There are no staging and production branches. At any time you can deploy master to staging. Once you're satisfied it's ready, you can deploy that commit to production. If you like you can also git tag staging or git tag production the commit which is deployed. This is the workflow used by things such as Heroku Pipelines.
What about hot patches?
Make a temporary branch off the production tag, git branch hot-patch production. Commit the hot patches to that branch. Deploy that branch.
Once the emergency is over, and as quickly as possible, redo the hot patches as a normal feature branch and normal deployment process. You can use git cherry-pick or git rebase to get the hot patch changes on top of master. Once the properly done fix is deployed, delete the hot patch branch.
answered Jan 1 at 21:21
SchwernSchwern
90.7k17103237
add a comment |
Git is not a release manager. You can force it to be one, but it won't work well.
Instead, here's the principles of a simple continuous release/delivery workflow.
There is one long lived branch, master.
Even in git, maintaining long lived branches is complicated and best avoided. You have one branch both to develop from and to deploy: master.
master is at all times ready for release.
Nothing goes into master that isn't ready for release. This gives developers a stable platform from which to develop on, QA a stable platform for testing, and you can deploy the latest complete features with confidence at any time.
All development happens in feature branches.
You keep master at high quality by doing all development in branches off master. This allows each task to be isolated from the others, and developers are free to experiment without breaking the build.
Put another way, your development, integration, testing, and acceptance phases all happen in feature branches. Maintenance also happens as discrete feature branches.
Feature branches are well defined and short lived.
Keeping with the idea that long lived branches are painful, feature branches should be associated with one ticket, issue, or story. The purpose of the branch should be well defined and it should be clear when it's done. Once it's done, the branch is deleted to ensure it is not reused and to avoid branch clutter.
Your analysis and design phases must result in implementation tasks which can be chopped up into discrete tasks which can be done in a short lived feature branch. This requires some practice to learn how to do.
Use git merge --no-ff to ensure the branch is preserved in the topology of the commit history. Use the merge commit message to record any important information about the branch for future archeology such as references to the issue it is solving.
A - B ------------- M - N - O [master]
/
C - D - E - F
These are known as "feature bubbles". They make it clear that commits C, D, E, and F were done as a commit and we should look at M for information about the branch. Use git log --graph --decorate to get such a view, or any number of Git history visualizers.
Feature branches are rebased onto master.
To avoid feature branches falling out of date, they are habitually brought up to date with master. No feature is considered complete until it has been brought up to date with master, conflicts resolved, and all tests passing.
To avoid excessive bookkeeping merges, use git rebase master to keep history clean. Here's an example of what an out of date feature branch looks like. The F - G "bubble" is a completed feature branch.
F - G
/
A - B ----- H [master]
C - D - E [feature]
And then after rebasing it.
git checkout feature
git rebase master
F - G
/
A - B ----- H [master]
C1 - D1 - E1 [feature]
Feature branches must pass CI and QA before merging.
This guarantees that master is at all times ready for release. Since feature branches are kept up to date with master, QA on the branch also QA's master after the merge.
Deploy master to staging and production.
This is what it's all leading to. There are no staging and production branches. At any time you can deploy master to staging. Once you're satisfied it's ready, you can deploy that commit to production. If you like you can also git tag staging or git tag production the commit which is deployed. This is the workflow used by things such as Heroku Pipelines.
What about hot patches?
Make a temporary branch off the production tag, git branch hot-patch production. Commit the hot patches to that branch. Deploy that branch.
Once the emergency is over, and as quickly as possible, redo the hot patches as a normal feature branch and normal deployment process. You can use git cherry-pick or git rebase to get the hot patch changes on top of master. Once the properly done fix is deployed, delete the hot patch branch.
answered Jan 1 at 21:21
SchwernSchwern
90.7k17103237
Git is not a release manager. You can force it to be one, but it won't work well.
Instead, here's the principles of a simple continuous release/delivery workflow.
There is one long lived branch, master.
Even in git, maintaining long lived branches is complicated and best avoided. You have one branch both to develop from and to deploy: master.
master is at all times ready for release.
Nothing goes into master that isn't ready for release. This gives developers a stable platform from which to develop on, QA a stable platform for testing, and you can deploy the latest complete features with confidence at any time.
All development happens in feature branches.
You keep master at high quality by doing all development in branches off master. This allows each task to be isolated from the others, and developers are free to experiment without breaking the build.
Put another way, your development, integration, testing, and acceptance phases all happen in feature branches. Maintenance also happens as discrete feature branches.
Feature branches are well defined and short lived.
Keeping with the idea that long lived branches are painful, feature branches should be associated with one ticket, issue, or story. The purpose of the branch should be well defined and it should be clear when it's done. Once it's done, the branch is deleted to ensure it is not reused and to avoid branch clutter.
Your analysis and design phases must result in implementation tasks which can be chopped up into discrete tasks which can be done in a short lived feature branch. This requires some practice to learn how to do.
Use git merge --no-ff to ensure the branch is preserved in the topology of the commit history. Use the merge commit message to record any important information about the branch for future archeology such as references to the issue it is solving.
A - B ------------- M - N - O [master]
/
C - D - E - F
These are known as "feature bubbles". They make it clear that commits C, D, E, and F were done as a commit and we should look at M for information about the branch. Use git log --graph --decorate to get such a view, or any number of Git history visualizers.
Feature branches are rebased onto master.
To avoid feature branches falling out of date, they are habitually brought up to date with master. No feature is considered complete until it has been brought up to date with master, conflicts resolved, and all tests passing.
To avoid excessive bookkeeping merges, use git rebase master to keep history clean. Here's an example of what an out of date feature branch looks like. The F - G "bubble" is a completed feature branch.
F - G
/
A - B ----- H [master]
C - D - E [feature]
And then after rebasing it.
git checkout feature
git rebase master
F - G
/
A - B ----- H [master]
C1 - D1 - E1 [feature]
Feature branches must pass CI and QA before merging.
This guarantees that master is at all times ready for release. Since feature branches are kept up to date with master, QA on the branch also QA's master after the merge.
Deploy master to staging and production.
This is what it's all leading to. There are no staging and production branches. At any time you can deploy master to staging. Once you're satisfied it's ready, you can deploy that commit to production. If you like you can also git tag staging or git tag production the commit which is deployed. This is the workflow used by things such as Heroku Pipelines.
What about hot patches?
Make a temporary branch off the production tag, git branch hot-patch production. Commit the hot patches to that branch. Deploy that branch.
Once the emergency is over, and as quickly as possible, redo the hot patches as a normal feature branch and normal deployment process. You can use git cherry-pick or git rebase to get the hot patch changes on top of master. Once the properly done fix is deployed, delete the hot patch branch.
answered Jan 1 at 21:21
SchwernSchwern
90.7k17103237
edited Jan 1 at 21:37
answered Jan 1 at 21:21
SchwernSchwern
90.7k17103237
answered Jan 1 at 21:21
SchwernSchwern
90.7k17103237
answered Jan 1 at 21:21
SchwernSchwern
90.7k17103237
90.7k17103237
add a comment |
add a comment |
1
Great question, but not a good fit for stack overflow.
– Dan Farrell
Jan 1 at 19:41