4 ms·
One of the fun challenges I have in my current job is that we provide releases to customers according to the customers schedule (which is related to needing hou
by VBprogrammer 7y ago
One of the fun challenges I have in my current job is that we provide releases to customers according to the customers schedule (which is related to needing hours of downtime because it's a creaky old system).
Some customers will skip releases altogether making strategies like add a new column, back populate it online, then the next release uses the new value impossible.
I guess that point is slightly moot when it'd take 2-3 releases to achieve the end goal and each release cycle is about a month.
- dillonmckay 7y agoOn the plus side for you, it seems you have each customer isolated from one another.
- jefftk 7y agoYou're not in a great situation, but there are still lessons from the post. For example, you could break upgrades into a series of changes that can be individually rolled back, and run smoke tests in between each one. But your biggest reliability improvement would come from getting this system moved to continuous deployment without downtime. Now you can make one change at a time and roll back if it doesn't work.
- aeorgnoieang 7y agoIf they're in anything like the last situation I was in that seems similar, continuous deployment may not be possible – not technically, but with respect to other considerations, e.g. management or even the business's finances. There's still a lot of small software companies maintaining, and selling, on-premises installations of systems that use, e.g. Microsoft Access as a front-end client. Even then, continuous deployment is possible, and all-else-equal, a huge improvement for the developers and support staff, but also something that lots of management or owners may be (reasonably) averse to committing to implementing.