4 ms·

I look back on my early web dev career where source control was something unheard of as were dev environments. In fact we regularly edited code live on prod ser

I look back on my early web dev career where source control was something unheard of as were dev environments. In fact we regularly edited code live on prod server to debug/develop. Looking back I just shudder thinking about it.

donatj 3y ago
Yup. We worked on a shared SMB server that had nightly backups. If we borked something bad enough to need to pull one of the backups it was an ordeal that involved calling (on the telephone) and potentially waking our IT guy who lived in Juneau Alaska Putting a site live just involved FTP-ing the files up to one our shared webservers.
stuaxo 3y ago
Numbered folders for version control sftp up to the live server.
- uxamanda 3y ago
  "/site-final2" "/site-final-final-4"
  - IggleSniggle 3y ago
    "/site-final-final-4.bak--prod3-rc0-23.live (1)"
lelandfe 3y ago
Worked for an agency that edited sites cowboy style over FTP, and whose “backup plan” for all agency data was a 500gb NAS. I found out that the designer just edited files directly on the NAS, so there was no backup. Classic.
Foobar8568 3y ago
Say hi to most DWH, DB developments...
toast0 3y ago
Everybody has a dev environment and a staging/qa environment. Places with better processes just have them so they're separate from production. :p IMHO, it's better to be a cowboy and reluctantly follow 'best practices' for the most part, than to be a 'best practices' person and be unprepared to be a cowboy when it's needed. Sometimes, the best way forward is to force an update on production, even if the only method you have is modifying the executable on disk, while it's running. It's mmaped, so you can do this. But you wouldn't know this if you hadn't broken production by using cp instead of install to update a binary you wanted to modify for the next load.

4 ms·

I look back on my early web dev career where source control was something unheard of as were dev environments. In fact we regularly edited code live on prod ser

by joshstrange 3y ago

donatj 3y ago
Yup. We worked on a shared SMB server that had nightly backups. If we borked something bad enough to need to pull one of the backups it was an ordeal that involved calling (on the telephone) and potentially waking our IT guy who lived in Juneau Alaska Putting a site live just involved FTP-ing the files up to one our shared webservers.
stuaxo 3y ago
Numbered folders for version control sftp up to the live server.
- uxamanda 3y ago
  "/site-final2" "/site-final-final-4"
  - IggleSniggle 3y ago
    "/site-final-final-4.bak--prod3-rc0-23.live (1)"
lelandfe 3y ago
Worked for an agency that edited sites cowboy style over FTP, and whose “backup plan” for all agency data was a 500gb NAS. I found out that the designer just edited files directly on the NAS, so there was no backup. Classic.
Foobar8568 3y ago
Say hi to most DWH, DB developments...
toast0 3y ago
Everybody has a dev environment and a staging/qa environment. Places with better processes just have them so they're separate from production. :p IMHO, it's better to be a cowboy and reluctantly follow 'best practices' for the most part, than to be a 'best practices' person and be unprepared to be a cowboy when it's needed. Sometimes, the best way forward is to force an update on production, even if the only method you have is modifying the executable on disk, while it's running. It's mmaped, so you can do this. But you wouldn't know this if you hadn't broken production by using cp instead of install to update a binary you wanted to modify for the next load.