We manage a growing number of FPBX systems. All systems are using the Sangoma distro, and all systems have standardized virtual machine hardware in the datacenters we host from and all that works fine (finally, it took a LOT of time to get that stuff all ironed out).
The main challenge still bugging us is how to handle/manage updates to the OS, and the updates to Freepbx modules.
Of course we can yum update the OS related stuff or use the System Updates in GUI, and then use the module admin to do the module updates, but I want to keep all updates on all systems consistent, as some module updates invariably introduce bugs or feature changes that would blindside us or the end users, so we don’t leave “auto-update” on for that reason either. I would like to approach this with “release rings” methodology ideally.
We’d have our inner ring with a lab system that we do initial testing with. Those updates are then “approved” by us to our next ring, which would consist of our own production PBX. After X time and we bless those updates at our ring, the next ring of a core group of clients can get them and after some more time the outer ring of clients can get those.
Currently when doing updates you can only update to “now” and not specifically install updates up to a certain level/date. I think the easiest way to define the “lines in the sand” update-wise would be to allow updates that existed as of X date rather than trying to police each modules individual versions
As an example, on one system I’ll use the FPBX Framework Module as an example. As of right this second it’s on 14.0.11. “check for updates” returns that as of right now the update will take me to 14.0.13.4. If I look at release notes there has been several iterations between 14.0.11 and 14.0.13.4, but we can’t select any of those as what we want to update to. We can only jump to the most current which is 14.0.13.4. The “Previous” feature allows me to roll back to updates that existed BEFORE my currently installed version. I could theoretically update to 14.0.13.4, then use the “previous” function to go down to a specific one, but that would be a ton of manual work on one system, let alone many.
Any ideas on how we can accomplish this?
