Hacker News Reader

Comment by simonw | Hacker News Reader

Here's a way to introduce version control without having to stop everyone and teach them how to use it first:

1. Commit the entire production codebase to git and push it to a host (GitHub would be easiest here)

2. Set up a cron that runs once every ten minutes and commits ALL changes (with a dummy commit message) and pushes the result

Now you have a repo that's capturing changes. If someone messes up you have a chance to recover. You can also keep track of what changes are being applied using the commit log.

You can put this in place without anyone having to change their current processes.

Obviously you should aim to get them to use git properly, with proper commit messages - and eventually with production deploys happening from your git repository rather then people editing files in production!

But you can get a lot of value straight away from using this trick.

It's basically a form of git scraping: https://simonwillison.net/2020/Oct/9/git-scraping/

View on HN

That git scraping technique is amazing! This is what a proper hack looks like. Super neat.

I'm immediately searching for public maps etc to apply this on.

How do you make sure that code being committed is ready to be run, files could be saved before they're ready. I'm assuming this won't happen on production server, but you can't be sure if it's just code workspace for someone.

This doesn't.

It's not perfect, it's a step in the right direction.

The system is an enormous black box and this at least tells you what N things were being manipulated at time in point X. Easy to setup and gives just a bit of peace and mind if the thing keels over one day.

You don't, but the current system doesn't do that either. That comes later down the line. Baby steps and all that!

A path to doing this might look like: - Cron job scraping and committing - add a post commit check that runs a linter/some checks/tests - assign out fixes to these issues - ask for those fixes to be done using git - pick an area to focus on, and enforce coverage in that area. You can still blindly deploy here, but at least you know when it's broken

As noble a goal of testing before deployment is, sometimes it's an enormous amount of effort to change development practices, workflows, team mindset and company mindset. You can only handle some of these at a time so choose a combination of the low hanging fruit (maybe there's a separate component) and the highest impact (every time this breaks the site goes down)

> Commit the entire production codebase to git and push it to a host (GitHub would be easiest here)

Git on his own machine would be easiest. There is no need to consider a git host that the others can access until things are at the point where the others are ready to use git.

Even when they reach that point I question whether GitHub is the way to go. He didn't say much about their IT department but they have web servers and databases so evidently have people who can manage such things. It would be close to trivial for those people to set up git hosting on one of their own servers.

Love your Git scraping technique, very clever. Thanks for sharing.

DB schema and prod/devops config too!

Reply on news.ycombinator.com