Hi all,
We are in the process of revamping a lot of fact sheets in the context of changes to our metamodel. We are using 3 workspaces to support a traditional Dev/PreProd/Prod path.
I’d like to know how you manage your configurations promotions from one to another? Example: I have added 10 new attributes on a fact sheet and a bunch of tags collection in my dev workspace and plan to push it forward. How do you guys manage that, other than manually re-applying the change in other environments?
Best answer by geoffrey.lowney
Many (but not all) changes can be made using the APIs, so you could consider using APIs (called from your preferred tool, such as Power Automate) to migrate changes automatically.
+2I’d love to see tools for this from LeanIX. I am not aware of anything out of the box.
As the only person making meta-model and other config changes in our two workspaces, I currently maintain a spreadsheet of all the changes (with dates for when they were applied to each workspace), and I manually make the same changes across the workspaces as it makes sense (in a few cases the config etc in sandbox should not match what we have in production).
I’d love to see tools for this from LeanIX. I am not aware of anything out of the box.
As the only person making meta-model and other config changes in our two workspaces, I currently maintain a spreadsheet of all the changes (with dates for when they were applied to each workspace), and I manually make the same changes across the workspaces as it makes sense (in a few cases the config etc in sandbox should not match what we have in production).
Since all the changes we make to the model translates into metadata, I was kinda hoping to be able to reapply the changes downstream without having to do what you just mentioned (we’re kinda stuck with a manual task).
The product seems doing what it should from an EA standpoint, however there are a lot of improvements that I can see from an application management perspective…
+2Many (but not all) changes can be made using the APIs, so you could consider using APIs (called from your preferred tool, such as Power Automate) to migrate changes automatically.
We do everything with clones and manually, literally, hand configure in sandbox, then try and remember what we did, and then hand configure in production - when we see something unexpected, we go into a cycle of troubleshooting.
We found some success in using clones, but found we had to still do manual changes anyways, sometimes clones introduced data issues because of our automated data integrations DURING OUR CHANGE WINDOW and upstream system changes that impact our LeanIX data:
(1) make all our changes in Sandbox that we think we want to “migrate”
(2) “clone production into test-A”, then
(3) freeze production - open our change window
(4) make our upgrades we identified manually in test-A then
(4) cloning test-A and put the test-A clone into production
(5) make any FURTHER MANUAL CHANGES IN PRODUCTION that do not come along with the test-A clone
(6) run validation tests in production, inspect/ manually navigate/ run test cases until we are satisfied everything looks right
(7) “unfreeze production”, close change window.
The guidance we got was “do everything in production”, you just need sandbox for really major impacts. We have thousands of apps (currently), and are in the early phases of LeanIX adoption - lots of change-, so most changes at this point in our adoption have a major impact on our user base.
We are about to do another major migration, so we’ll be looking at this process again, some ideas for improvement are:
Our issue is TIME/MONEY/IMPACT tradeoffs. Our SLA has been 7 days, but as we bring on more users, our SLA may shrink to 24 hours. Then we ask - what's the financial impact (people/time) of being down if our migration completely fails.
we’ve not had any major failure on our migrations yet (bad data in prod for longer than 48 hrs).
Many (but not all) changes can be made using the APIs, so you could consider using APIs (called from your preferred tool, such as Power Automate) to migrate changes automatically.
Indeed, however it’s always a bit tricky when updating config via APIs where there are no safeguards… But I’ll definitely take a look. Thanks,
+2I think the safeguards are up to your coding (or low-coding) skills 😆. I agree, with your comment, and with the suggestion that LeanIX should (at some point) provide robust tools around configuration migration/promotion.
+1Hello community!
Firstly, let me express my gratitude for your insightful feedback. Your thoughts and ideas are the cornerstone of our continuous improvement, and we truly appreciate the time and effort you put into sharing them with us.
Your suggestions related to the tooling proposal have indeed piqued our interest. We are keen to delve deeper into this internally, exploring how we can enhance our ecosystem of public facing assets.
Your ideas could be the catalyst 😉 for improvements and extensions in our offerings. We appreciate your input and look forward to exploring its potential.
Hello community!
Firstly, let me express my gratitude for your insightful feedback. Your thoughts and ideas are the cornerstone of our continuous improvement, and we truly appreciate the time and effort you put into sharing them with us.
Your suggestions related to the tooling proposal have indeed piqued our interest. We are keen to delve deeper into this internally, exploring how we can enhance our ecosystem of public facing assets.
Your ideas could be the catalyst 😉 for improvements and extensions in our offerings. We appreciate your input and look forward to exploring its potential.
Thanks for taking it into consideration.
If the product is supposed to be managed using more and more of a “low-code/no code” approach, there are definitely some improvements you should bring to the administration part. The case of
I would gladly be part of your focus group to provide some feedback. :-)
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
