Dear Celonis,
not sure if such a feature request already exists. If yes, then please ignore. Otherwise - it would be great to have a built in possibility for versioning, especially for data jobs, but actually for the whole instance. Or in general test/production environment concept.
thanks
Masha
Page 1 / 1
Hi Masha,
Thank you for very much for your feature proposal.
What would you use the versioning for, i.e. how would you use the versions in our daily work? How do you currently work around the fact that there is no versioning?
Best regards,
Leonid
Thank you for very much for your feature proposal.
What would you use the versioning for, i.e. how would you use the versions in our daily work? How do you currently work around the fact that there is no versioning?
Best regards,
Leonid
Hello Leonid,
we would use it for the case if we, for example, created a new version, and after the load it is not working, or we realized that its wrong etc. And we already changed the code so much that we cannot simply go back and change it manually. Then it would be good to have an option to roll-back to the previous working version.
Currently before I change any code I copy-paste it as a whole and copy it in comments section at the end of a particular data job.
we would use it for the case if we, for example, created a new version, and after the load it is not working, or we realized that its wrong etc. And we already changed the code so much that we cannot simply go back and change it manually. Then it would be good to have an option to roll-back to the previous working version.
Currently before I change any code I copy-paste it as a whole and copy it in comments section at the end of a particular data job.
Thank you for the explanation.
We have it on the roadmap to be able to restore Data Jobs and their content to previous versions.
We have it on the roadmap to be able to restore Data Jobs and their content to previous versions.
When is the approximate planned release time for that feature?
Probably by the beginning of next year, but potentially also sooner
Dear Masha,
Currently we are backing-up all our transformations using the Machine Learning Workbench and store it using GIT. This use case is explaned here: https://python.celonis.cloud/docs/pycelonis/en/latest/notebooks/99_Use_Case_Version_control.html.
Note that this requires quite some Python coding, especially if you want to create a function that can restore specific parts of the data jobs. However, we also use this solution right now to rename table or column names in all our data jobs, by just applying a string replace and then put them back. So investing some time in this could be very beneficial
Hopefully this helps you with your use case.
Bests,
Jan-peter
Currently we are backing-up all our transformations using the Machine Learning Workbench and store it using GIT. This use case is explaned here: https://python.celonis.cloud/docs/pycelonis/en/latest/notebooks/99_Use_Case_Version_control.html.
Note that this requires quite some Python coding, especially if you want to create a function that can restore specific parts of the data jobs. However, we also use this solution right now to rename table or column names in all our data jobs, by just applying a string replace and then put them back. So investing some time in this could be very beneficial
Hopefully this helps you with your use case.
Bests,
Jan-peter
Hi Leonid,
I have been discussing this with Celonis through our IBC migration project. This way of rolling back to a previous version is pretty old-school. Usually there is one area in the code-base causing the problem. Rolling back to a previous version means you lose the good stuff and have to incoporate this back in. Sometimes you dont know what is causing the problem, and you can experiment with commit-level rollbacks to find the cause of the error.
Most people rely on Git whilst developing code. Im pretty amazed that this hasnt been incorporated into IBC for versioning. Whilst we can hack the system through a myriad of python scripts to push code to a git repo, the system would greatly benefit from proper versioning & history through the use of GIT. Wed like to use branch & merge methodology, pull requests for code review, roll backs (at the commit level through cherry picks) etc. We do this with our on-prem version, so were really struggling to get our head around this step backwards as a result of our migration.
Kind regards,
Bronwyn
I have been discussing this with Celonis through our IBC migration project. This way of rolling back to a previous version is pretty old-school. Usually there is one area in the code-base causing the problem. Rolling back to a previous version means you lose the good stuff and have to incoporate this back in. Sometimes you dont know what is causing the problem, and you can experiment with commit-level rollbacks to find the cause of the error.
Most people rely on Git whilst developing code. Im pretty amazed that this hasnt been incorporated into IBC for versioning. Whilst we can hack the system through a myriad of python scripts to push code to a git repo, the system would greatly benefit from proper versioning & history through the use of GIT. Wed like to use branch & merge methodology, pull requests for code review, roll backs (at the commit level through cherry picks) etc. We do this with our on-prem version, so were really struggling to get our head around this step backwards as a result of our migration.
Kind regards,
Bronwyn
Hi Bronwyn,
Using a git-like approach is also a possibility that we are considering and we are very grateful for your feedback on the matter.
Best regards,
Leonid
Using a git-like approach is also a possibility that we are considering and we are very grateful for your feedback on the matter.
Best regards,
Leonid
Great to hear. Happy to be the guinea pigs for product development if you need a test case 
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.