7 ms·

To give another perspective, at my first job deploying meant sshing into production and execute a make script. It worked 98% of the time, and you'd be having fu

To give another perspective, at my first job deploying meant sshing into production and execute a make script. It worked 98% of the time, and you'd be having fun the 2% else. It sure wasn't the state of the art, but wasn't something people would yell at you for. We needed windows machine because of corporate policy and remoted into a Solaris box to dev, as a vague replica of production. Fast forward to today, and we can run a production replica on our local machines at home, the CPU architectures aren't even the same, and code will be deployed through the CI automatically after the tests all pass. Sure not all changes are meaningful, but in the grand scheme of things the field is moving forward in spades. I certainly wouldn't want to go back a few decades.

coldtea 3y ago
>Fast forward to today, and we can run a production replica on our local machines at home, the CPU architectures aren't even the same, and code will be deployed through the CI automatically after the tests all pass. And someone we squandered most of the CPU performance increases in the process, and the super-duper architecture/CI/delivery pipeline fails almost the same percentage of the time, but needs 10x the people to keep it running...
- makeitdouble 3y ago
  CI and delivery failing 2% of the time just means you haven't deployed and you just retry. At least you're not poking things in prod. I'm with you on the CPU gains going down the drain and 10x more people working on it, but it's also a sign that we're talking IT operations more seriously and there's enough money to cover these kind of inefficiencies.
shocks 3y ago
Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in, viming a file, and hacking it a few times. These days, if you leave the app untouched for six months that 10 minute fix becomes 2 hours of fixing a broken docker build. :)
- ilyt 3y ago
  As an admin of PHP apps at that time I can sincerely say screw you, you're lying. PHP apps breaking because new version of PHP shat on compatibility was pretty common, and weirdly enough got more common in newer versions. You also had to keep unholy combo of php extensions (why that garbage is in app server and not app) and server config because the special little retard that designed the app decided he must do something different. And forget about ever leaving apache, if it doesn't use some apache module to fix PHP/developer ineptitude it will at least have half of the request routing logic in .htaccess file.
  - shocks 3y ago
    > forget about it for a few years No version upgrade required. :D
    - andrelaszlo 3y ago
      Haha yeah I can say, with the same sincerity, that I get occasional calls about fixing PHP apps that I built 2007-2013. They've been running (without upgrades) on some forgotten server in a multinational corporation. I tell them that they should let their compliance department know, that the version of PHP isn't even supported, and I list some of the thousand security fixes that they aren't using. I usually end up VPN/FTP:ing into a forgotten era to add the fixes and I definitely don't want to go back.
      - progmetaldev 3y ago
        I had this happen about a year and a half ago with an application I wrote in 2009. Finally got them to allow me to rewrite everything in C#, allowing me to keep up to date on security vulnerabilities and performance improvements, without having to do much but run through a series of tests when a NuGet package or .NET version upgrade is released. NuGet with current .NET is a far different beast now, than when you used .NET Framework and plenty of XML assembly binding.
    - mm007emko 3y ago

coldtea 3y ago

>Fast forward to today, and we can run a production replica on our local machines at home, the CPU architectures aren't even the same, and code will be deployed through the CI automatically after the tests all pass. And someone we squandered most of the CPU performance increases in the process, and the super-duper architecture/CI/delivery pipeline fails almost the same percentage of the time, but needs 10x the people to keep it running...

makeitdouble 3y ago
CI and delivery failing 2% of the time just means you haven't deployed and you just retry. At least you're not poking things in prod. I'm with you on the CPU gains going down the drain and 10x more people working on it, but it's also a sign that we're talking IT operations more seriously and there's enough money to cover these kind of inefficiencies.

shocks 3y ago

Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in, viming a file, and hacking it a few times. These days, if you leave the app untouched for six months that 10 minute fix becomes 2 hours of fixing a broken docker build. :)

ilyt 3y ago
As an admin of PHP apps at that time I can sincerely say screw you, you're lying. PHP apps breaking because new version of PHP shat on compatibility was pretty common, and weirdly enough got more common in newer versions. You also had to keep unholy combo of php extensions (why that garbage is in app server and not app) and server config because the special little retard that designed the app decided he must do something different. And forget about ever leaving apache, if it doesn't use some apache module to fix PHP/developer ineptitude it will at least have half of the request routing logic in .htaccess file.
- shocks 3y ago
  > forget about it for a few years No version upgrade required. :D
  - andrelaszlo 3y ago
    Haha yeah I can say, with the same sincerity, that I get occasional calls about fixing PHP apps that I built 2007-2013. They've been running (without upgrades) on some forgotten server in a multinational corporation. I tell them that they should let their compliance department know, that the version of PHP isn't even supported, and I list some of the thousand security fixes that they aren't using. I usually end up VPN/FTP:ing into a forgotten era to add the fixes and I definitely don't want to go back.
    - progmetaldev 3y ago
      I had this happen about a year and a half ago with an application I wrote in 2009. Finally got them to allow me to rewrite everything in C#, allowing me to keep up to date on security vulnerabilities and performance improvements, without having to do much but run through a series of tests when a NuGet package or .NET version upgrade is released. NuGet with current .NET is a far different beast now, than when you used .NET Framework and plenty of XML assembly binding.
  - mm007emko 3y ago