0
I have the following scenario: 3 programmers (P1,P2,P3) with their local production environments, a QA test server and a production server. According to the company’s business rules there are modifications in the Systema that must go to production, even before being tested and as usual, there are changes that must spend time in the QA before being sent to production.
The production environment only PULL from the QA server, just as programmers only pull and push to the QA.
My question is when the 3 programmers P1, P2 and P3 do their pushes,for QA, but when I pull QA to production I just want the changes made by P1 and P3. P2 modification will need to stay longer being tested.
I don’t know how to separate these branches at pull - I don’t even know if it’s possible.
myapp-P1 ---
\
myapp-P2 --- ---> myapp-staging (QA) ---> myapp (Prod)
/
myapp-P3 ---
Someone could give an idea?
Have you considered using the git flow?
– Carlos Fernandes
Hi Carlos, yes, I’ve spent the day taking a look at git flow but I haven’t found any idea that could answer this scenario. Tbm gave a read on www.atlassian.comand found nothing. So I came to ask here in the community to know how people deal with this situation.
– zwitterion
I believe git flow serves you or you might consider working with project forums. Where each developer will get their version of the code and send one
pull requestto the main repository, so QA can test thepull requestbefore joining the main code. Heroku’s pipeline works this way, see.– Carlos Fernandes
@zwitterion its context is IC (Agreement, or continuous integration)? A build server that pushes to production?
– OnoSendai
We are 3 programmers. The company has a central QA repository, as I modified above. Yes, I could say that we work on a logic of continuous integration, but sometimes only 1 programmer for a certain day does the pushs. (pq only he finished the code). There in this scenario it is easy to solve the problem.
– zwitterion
The worst is when everyone pushes and the people who test, discovers that there is a flaw in the change of one of the programmers but the production needs to be updated with QA instantly, or when we do not want to delete what the P2 programmer did (although his code is correct and the staff has to test in QA, it is not the time to send to production)
– zwitterion
Work with branchs, and 1 branch will be Production, in this branch you only do the pull requests that should be in production. E dev you do the branchs boot to be tested.
– Marco Vinicius Soares Dalalba
You ever heard of Cherry-pick? But I think you should work better on your branch process and strategy, and use this Feature https://git-scm.com/docs/git-cherry-pick
– egomesbrandao
Hi @egomesbrandao I’m going to take a look. I knew Herry-pick. And yes, we’re going to have to work on that branch strategy. It’s giving you a headache.
– zwitterion
@zwitterion It seems to me that you need an intermediate environment before production. It is usually called staging area. Exactly works for testing post-integration errors.
– OnoSendai
I believe you would need to review this branch strategy. The ideal is that there was a branch of things already tested and that go to production, type "pre-production". So developers would send QA to pre-production only when everything was tested.
– Giuliana Bezerra