There is no excuse for “open-heart-surgery” in solution development. Developing, testing and using a file is easier than ever using FMDMT. But it also poses difficulties, that were not on our radars 5 years ago.
Has a developer changed something in the file with the customer, that has not come back to the Dev-Version?
What has changed since the last roll-out?
Did I break it, or was it always broken and nobody noticed?
Is it safe to roll out and how long will this take?
Following the circle of life of a new version of a solution we have worked hard to get the following issues solved:
The Life-Cycle of a file
Every Dev-File can have many Stage-Files
Every Sage-File has exactly one Prod-file
- How do you document, this genealogy of every Prod-File?
- Where to note the version so that it survives data migration?
- How do you automate this process?
- How can you build your change-log from your lines of code, documenting your decisions?
Distributed development files
In a multi-file solution one file can be in development on one server, while the others are on a different server.
- How do you document this?
- How can you guarantee, to always take the newest clone for a file before you do a roll-out?
Clones from different servers have different encryptions@rest.
- How not to play the guessing game when doing a data migration?
Remote FMDMT process
Customers servers behind firewalls, headless Linux servers.
- How do you safely transmit clones, FMDMT, Passwords, E@R’s?
- How do you handle a broken migration, with minimal holdup?
I will present the underlying concepts and demonstrate the individual solutions to these.
Read more about Philipp