4 ms·

When I started my last job they weren't using version control, so I just told them that if nothing else it would be very easy and painless to just check in ever

When I started my last job they weren't using version control, so I just told them that if nothing else it would be very easy and painless to just check in every time we push to production so that we always have a snapshot of the last version. The problem with them was that their developer would go and make changes to files in production to fix bugs and issues, even after started using version control, so it was always a chore keeping up with his hotshot prod changes. You don't have to implement a full continuous integration environment or start branching each developer separately, you can just start catching snapshots along the way and it will have a positive impact on future development.

btilly 17y ago
The right solution to that is to overwrite his "hotshot prod changes" from version control until he learns that he has to do it in version control first. If you don't have enough political pull to make that stick, then you have a second problem...
- gte910h 17y ago
  Or you check in the production changes.... If you can't do this from your source control system, try something more powerful.
  - btilly 17y ago
    That is a workaround but it has two major shortcomings. The first is that you aren't getting the other developers to use source control. The second is that you wind up with the challenge and the blame for breaking it in the case where someone fixed it in production, someone else checked a different fix into source control, and you are expected to merge them. The simple rule, "You knew I was going to go from version control, your fault for not fixing it in there" is a proven technique for getting people to actually use version control. I've seen it done, and know people who did it at several other organizations and it works. (Though at this point my first impression of developers that don't know how to use version control is that they must be incompetent people I'd prefer not to work with. Not using version control a decade ago was somewhat more excusable than not know about it today.)
    - gte910h 17y ago
      >"You knew I was going to go from version control, your fault for not fixing it in there" is a proven technique for getting people to actually use version control. I've seen it done, and know people who did it at several other organizations and it works. I know being an ass to people works. Tried and true for sure, very passive aggressive technique to get developers to do things. Also just keeping a production branch and development branch works too. Check in the production changes to production branch. Production hotshot doesn't port over changes or at least mention the important ones to the guys working on the dev team? Kick that poor behavior to his boss about how he's not pulling his weight, staffing problems are HIS problem not yours, and by strongarming the guy with passive aggressive overwrites, you're screwing the company AND the hotshot, rather than just the hotshot.
- abyssknight 17y ago
  I'll second that. It's politics, and unfortunately, you need a business case to push policy. Wait until the next production outage caused by nasty, ad-hoc changes and point at the version control system and say, "If we had this, we could just roll it back." I'd almost say your build process has to accommodate version control first. Capistrano is pretty good at that. If you have a developer with production access, you're bound to get stuff like this.

btilly 17y ago

The right solution to that is to overwrite his "hotshot prod changes" from version control until he learns that he has to do it in version control first. If you don't have enough political pull to make that stick, then you have a second problem...

gte910h 17y ago
Or you check in the production changes.... If you can't do this from your source control system, try something more powerful.
- btilly 17y ago
  That is a workaround but it has two major shortcomings. The first is that you aren't getting the other developers to use source control. The second is that you wind up with the challenge and the blame for breaking it in the case where someone fixed it in production, someone else checked a different fix into source control, and you are expected to merge them. The simple rule, "You knew I was going to go from version control, your fault for not fixing it in there" is a proven technique for getting people to actually use version control. I've seen it done, and know people who did it at several other organizations and it works. (Though at this point my first impression of developers that don't know how to use version control is that they must be incompetent people I'd prefer not to work with. Not using version control a decade ago was somewhat more excusable than not know about it today.)
  - gte910h 17y ago
    >"You knew I was going to go from version control, your fault for not fixing it in there" is a proven technique for getting people to actually use version control. I've seen it done, and know people who did it at several other organizations and it works. I know being an ass to people works. Tried and true for sure, very passive aggressive technique to get developers to do things. Also just keeping a production branch and development branch works too. Check in the production changes to production branch. Production hotshot doesn't port over changes or at least mention the important ones to the guys working on the dev team? Kick that poor behavior to his boss about how he's not pulling his weight, staffing problems are HIS problem not yours, and by strongarming the guy with passive aggressive overwrites, you're screwing the company AND the hotshot, rather than just the hotshot.
abyssknight 17y ago
I'll second that. It's politics, and unfortunately, you need a business case to push policy. Wait until the next production outage caused by nasty, ad-hoc changes and point at the version control system and say, "If we had this, we could just roll it back." I'd almost say your build process has to accommodate version control first. Capistrano is pretty good at that. If you have a developer with production access, you're bound to get stuff like this.