Skip to content
This repository has been archived by the owner on Jul 16, 2021. It is now read-only.

version management #20

Open
pratibhakalmath opened this issue May 21, 2019 · 6 comments
Open

version management #20

pratibhakalmath opened this issue May 21, 2019 · 6 comments

Comments

@pratibhakalmath
Copy link

Hi Team, I had a query ( not an issue ) when the application gets built and deployed again on the SCP after the Jenkins pipeline detects some changes in the code, the previous version gets lost . I there a way where we can still have the previous versions on the SCP when the new versions gets deployed.
Thanks.

@radsoulbeard
Copy link
Contributor

It depends on your use case. You could have e.g. different accounts to reflect different quality stages, like DEV, QUAL, PROD where in DEV you deploy each commit and into QUAL and PROD you deploy after some validation steps. This can be achieved in a Jenkins pipeline or with SAP Cloud Platform Transport Management Service.
And if you just want to play around you could rename the application temporarily. But this is not useful for productive use cases.

@benhei
Copy link

benhei commented May 21, 2019

Hi,

I'm not sure about your context which might be special. On a general level I would say that the "cloud-native way" would be to:

  • Invest into automated tests that qualify new versions of your service, thus, avoiding that regressions occur in production.
  • If there's an issue in production (which can of course still happen from time to time), you come up with a fix that (thanks to your automated pipeline) quickly finds its way into production.

Hope this helps.

Best,
Benjamin

Edit: The "audit trail" of your deployments may additionally be stored in a artifact store such as nexus.

@pratibhakalmath
Copy link
Author

Scenario: we have an application deployed on the SCP as version 0.0.1, if we make some changes the Jenkins detects the changes and hence builds and deploy the application again on the SCP say as version 0.0.2 . The issue when the application gets deployed on the SCP as version 0.0.2 the previous version i.e. 0.0.1 gets deleted. Is it possible that we can still have the previous versions on the SCP even though a new versions gets deployed?
Please share your thoughts.Thanks.

@benhei
Copy link

benhei commented May 22, 2019

Would you mind elaborating why you want to do that?

@pratibhakalmath
Copy link
Author

Suppose we have an application deployed on the SCP as version say 0.0.1 with feature A. If we make some changes in the application and deploy it again on the SCP as version say 0.0.2 with feature B. However we realize the earlier feature was more better we instead of reverting the changes and deploying the application again on the SCP, can use the version 0.0.1. Please share your thoughts on this.Thanks.

@pratibhakalmath
Copy link
Author

Hi Team , waiting for your views on this.Thanks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants