I love discovering existing tools that can be used in new ways. This way to use git in a way I had not heard of is so badass (and by badass, I mean it’s going to save me an insane amount of time) that I have to shout it from the rooftops.
I work for a marketing firm with many clients. Developers bounce on & off projects as schedules allow. As such, we usually don’t know if doing a “full deploy” to our integration environment will break anything, which creates a lot of fear-driven, conservative pushes.
In other words, as a general rule we pull down from source control, have to keep track of exactly what files changed for each feature, and manually deploy (ONLY) those specific, affected files.
This is a very tedious, time-consuming and frustrating way to do things.
Because of the way Git stores content based on content (heh, imagine that) without regard for “file save date” shenanigans, I had the idea to try comparing our integration environment (before & after publishing via Visual Studio) using Git
I mapped the integration server to a local drive letter, then pathed to it & did:
- git init
- git add .
- git commit –m “state of integration server before local deployment”
- git checkout –b “20120824_1112am_FeatureId_FeatureName_ItgDep”
I then published from Visual Studio, using Publish method: “File System” with “Replace matching files with local copies” & ran:
- git diff –filename-only
From there, I am now investigating the files that changed & determining why they changed (fewer than I thought it would be in this case – hooray!!).
Once I get these discrepancies sorted out, I’ll be able to deploy directly, moving foreword, saving myself SO MUCH TIME in the future. That rocks!
The coolest thing is, I was able to do this without fear of messing up the integration environment, since either a git checkout master or a git reset –hard HEAD would revert any changes made by my Visual Studio deployment.
Extending this Discovery
- A git diff after publishing from Visual Studio with the “Delete all existing files prior to publish” option selected would be a great way to see what files exist in our integration environment that aren’t being deployed from Visual Studio (discover .flv files without proper Build Action property, images coworkers might have pushed but forgotten to add in TFS, etc).
- Given access to files in other environments (staging, production), an xcopy from one to the other after init could serve as a great way to do initial file content investigation between multiple environments as well.