You managed to agree with me without understanding the discussion.
Lets say you run a build that compiles v2.0 branch and store the artifacts as myproduct-2.0.2.tar.gz
You deploy that to your QA environment. Your testers have it and when they are done the results "looks good, time to release it to prod.
What you should do is take your build an promote it to released status. Now this can be picked up by customers or deployed to prod.
But, believe it not, there are people that branches named dev, test, prod. So when they complete testing on the artifacts above, they run another build on the prod branch and either release that to customers or deploy on internal prod.
You’re saying the same thing as me – when they do that prod build, its not the same artifacts as they tested in QA. In fact, anything you tested previously is no longer relevant because you have a new build.
It is not the same build.
A variable (a timestamp) is being changed, so by definition it is not the same build.
You managed to agree with me without understanding the discussion.
Lets say you run a build that compiles v2.0 branch and store the artifacts as myproduct-2.0.2.tar.gz
You deploy that to your QA environment. Your testers have it and when they are done the results "looks good, time to release it to prod.
What you should do is take your build an promote it to released status. Now this can be picked up by customers or deployed to prod.
But, believe it not, there are people that branches named dev, test, prod. So when they complete testing on the artifacts above, they run another build on the prod branch and either release that to customers or deploy on internal prod.
You’re saying the same thing as me – when they do that prod build, its not the same artifacts as they tested in QA. In fact, anything you tested previously is no longer relevant because you have a new build.
Can we both agree this debate is getting a bit long?
Anyway, the debate made me think a lot about this stuff.
I hope I encounter you online again, some day…