0

We have 5 enviornments, DEV, SIT, UAT, PT, PROD. We want the flexibility to deploy different code in different environments. So we created 5 branches on GitHub.

The issue we are facing is in distinguishing the artifacts. We only have one build server and if I give a build on that from SIT branch it will replace the artifacts of DEV from .m2 folder as the version no is same.

Now this impact us in case of dependent components. We have 15 child components and there artifacts are being used by other components at the time of build. Which is getting picked up from .m2 folder.

Is there a way I can distinguish the artifacts of each environment and then use it accordingly. I dont feel major problem in separating as I can tag them at the time of maven build. But then it will not be picked up by other components as the version will include a tag.

Any help will be appreciated.

Vijay_Yadav
  • 107
  • 1
  • 9
  • 1
    What makes the artifacts different between envs? You should be distinguishing the code from the configuration. Can't you parameterize the configuration differences into properties or something? Overlay? More details. – Ian W Dec 02 '20 at 10:51
  • Can't you parameterize the configuration differences into properties - This we are already doing. The difference is in code itself. Suppose we have 10 fix in dev of which 5 are tested, and we need to move those 5 to sit. There we need difference in code. – Vijay_Yadav Dec 02 '20 at 11:15
  • This can be achieved by using branches... no... – khmarbaise Dec 02 '20 at 12:38
  • This - " Suppose we have 10 fix in dev of which 5 are tested, and we need to move those 5 to sit." is not the right approach. You should always apply your "fixes" to Dev. Build from Dev, deploy the built artifact to DEV env, then if it passes, to SIT env, then to UAT -> - PT-> PROD. Branching by env is generally not a productive model; it is an anti-pattern. See next comment. – Ian W Dec 02 '20 at 19:10
  • See branching strategies: [trunkbaseddevelopment](https://trunkbaseddevelopment.com/alternative-branching-models/), [Git](https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows), [MS Git](https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops), [MS TFVC](https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/branching-strategies-with-tfvc?view=azure-devops), [Amazon AWS](https://aws.amazon.com/blogs/devops/implementing-gitflow-using-aws-codepipeline-aws-codecommit-aws-codebuild-and-aws-codedeploy/) – Ian W Dec 02 '20 at 19:11

0 Answers0