4 ms·

We are also running on Rails - and loving it, too. However, incorporating this methodology into our workflow would be both a lot of work to set up and also a l

We are also running on Rails - and loving it, too. However, incorporating this methodology into our workflow would be both a lot of work to set up and also a lot of work to keep running. There certainly is a size threshold under which this is clearly an overkill and we are under that threshold. Yet, if this could be turned into a product, a clean integration, a command I need to run... would definitely use it (and pay for it).

nevir 4y ago
The main cost is maintaining high test coverage so that you can be confident in your automation
New_California 4y ago
On the contrary, it is so much easier to upgrade a small app every week or so because you have little to test and probability of breaking changes affecting you is minimal. You should be upgrading all the time since day one, adding necessary infrastructure gradually as your app grows.
- ravloony 4y ago
  Absolutely. I was leading a team a while ago and I instituted this practice to good effect. Conversely, I was called by a company that I had built an app for previously. They had not upgraded the framework it was built with (Laravel), and ended up offering me consulting days to jump several versions. The irony is that the job ended up being quick and easy to do.
  - jonwinstanley 4y ago
    Yes, Laravel does a good job of making upgrades relatively simple
  - yurishimo 4y ago
    Laravel is relatively painless to upgrade as long as you have the autonomy to get the work done in a timely manner. I've seen upgrade projects drag on for weeks causing issues upstream since most of the team was still working on the product or fixing bugs while one developer was tasked with the upgrade. Did you use a tool like Shift to help with the upgrade? What about frontend dependencies? The recent move from Mix to Vite is great, but if you have a large frontend, it can be a major PITA to update. More so if you have any sort of custom webpack configuration.
- riffraff 4y ago
  You need to have the right infrastructure/organizational maturity tho. For example in many organizations partial deployments don't exist and rollback is not easy, so having a "once a quarter we test everything and bump" is less traumatic and expensive than handling minor breakages every week. You can invest into that infrastructure/maturity but it may not be the best use of your time and money if you don't even know that your company will exist next year.
tetha 4y ago
I've been similar discussions with our security guy and a few of our build infrastructure guy, and yeah. I think the pattern to consider is: (i) Yes, this would improve our deployment speed/upgrade speed/security posture, possibly by a huge amount. (ii) We have much bigger problems with higher impact. Like, at work, we could spend a month or so to setup something like dependabot for our private stuff and I'm pretty sure we could get to a point of deploying these dependency updates quickly - or, for less critical systems, automatically even. And it would be cool. But that won't help us with some of the flagship products in the company that have C++ dependencies on EOL windows components and no automated deployments. We'd rather have the capable guys working on these nasty issues, since these upgrades for the modern products can usually be done by a junior dev in a few days for all of these smaller and well-controlled systems.

nevir 4y ago

The main cost is maintaining high test coverage so that you can be confident in your automation

New_California 4y ago

On the contrary, it is so much easier to upgrade a small app every week or so because you have little to test and probability of breaking changes affecting you is minimal. You should be upgrading all the time since day one, adding necessary infrastructure gradually as your app grows.

ravloony 4y ago
Absolutely. I was leading a team a while ago and I instituted this practice to good effect. Conversely, I was called by a company that I had built an app for previously. They had not upgraded the framework it was built with (Laravel), and ended up offering me consulting days to jump several versions. The irony is that the job ended up being quick and easy to do.
- jonwinstanley 4y ago
  Yes, Laravel does a good job of making upgrades relatively simple
- yurishimo 4y ago
  Laravel is relatively painless to upgrade as long as you have the autonomy to get the work done in a timely manner. I've seen upgrade projects drag on for weeks causing issues upstream since most of the team was still working on the product or fixing bugs while one developer was tasked with the upgrade. Did you use a tool like Shift to help with the upgrade? What about frontend dependencies? The recent move from Mix to Vite is great, but if you have a large frontend, it can be a major PITA to update. More so if you have any sort of custom webpack configuration.
riffraff 4y ago
You need to have the right infrastructure/organizational maturity tho. For example in many organizations partial deployments don't exist and rollback is not easy, so having a "once a quarter we test everything and bump" is less traumatic and expensive than handling minor breakages every week. You can invest into that infrastructure/maturity but it may not be the best use of your time and money if you don't even know that your company will exist next year.

tetha 4y ago

I've been similar discussions with our security guy and a few of our build infrastructure guy, and yeah. I think the pattern to consider is: (i) Yes, this would improve our deployment speed/upgrade speed/security posture, possibly by a huge amount. (ii) We have much bigger problems with higher impact. Like, at work, we could spend a month or so to setup something like dependabot for our private stuff and I'm pretty sure we could get to a point of deploying these dependency updates quickly - or, for less critical systems, automatically even. And it would be cool. But that won't help us with some of the flagship products in the company that have C++ dependencies on EOL windows components and no automated deployments. We'd rather have the capable guys working on these nasty issues, since these upgrades for the modern products can usually be done by a junior dev in a few days for all of these smaller and well-controlled systems.