mogge
mogguh
Morgen, maybe finally going to ‘production’ today. With a project they started on 3 years ago..
exciting
Might take some time longer.. very happy that I’m just along the last half year for this project and not from start.
I remember someone giving a talk a while back and told the story about his job having yearly release cycles. But once they released they had to do a lot of bug fixes. To prevent this issue, management thought of the idea to have a two year release cycle instead of one. The speaker suggested to them that maybe it would be better to release faster. At which point he almost lost his job
@thomas Can you explain that Thomas, since I don't understand what the advantage would have been of 'cloud first'? What if that scenario went wrong: upgrade the cloud: OK, but releasing onPrem: fail?
on cloud you can make lots of little updates. CI/CD. deploying several times a day.
with a onPrem solution that is not really possible as companies only want to upgrade once is a while. (not automated downloads of new packages as your Linux distro for instance)
does that make sense @roger429?
Ah, OK. But there's not a (big) problem then of functionality being out-of-sync (one colleague using onPrem version 1.x, other colleague using cloud version 1.x+n)?
I guess customers used one ot the other.
(this was enterprise stuff)
Thx for elaborating!
Releases go fine, and we are in full control of those. The problem is getting other teams to use or services. In fact we did all the coding on there product to use our service..
that is just so appalling... as he was right of course.
Huh.. Unless it's avionics software or something very very mission critical.. That doesn't make much sense.
not sure I agree... the problem here is that they wrote lots of code, never tested it properly and then tried to do a big bang update. For mission critical (Avionics) software you would do loads more testing and do things like proofs etc. very different process.
Oh I didn’t say mornin’ today
You make a good point, I assumed testing was done in between long release cycles
Mornin’
considering they had lots of bugs the testing wasn't that good....
but it reminded me of story from one of my previous employers.... they released the onPrem version first and then tried to upgrade the cloud... and this failed... so they reverted to the old version... and then the execs demanded new functionality before attempting to upgrade again.
and that would fail as well of course...
rinse and repeat
they should have done cloud first of course.
Acceptance went fine, so prod tomorrow morning. Than finally end users will use our service 😀
Yes, I also like libraries that first put the code in production, before making a release. Lacinia does this.