Wednesday, August 24, 2011

Azure Fast-Deploy

We have been building a web system on Windows Azure for quite a while now in my company, and are very familiar with the 20 minute development cycle of redeploying an Azure Role. Recently, the Windows Azure team released a streamlining process for doing web deployments to Azure (for development purposes only, not production deployments). Andy Cross talks about it here:

The azure team blog talks about it here.

We tried to use Web Deploy, but we don't do things from Visual Studio. We instead do everything from the command line for our automation (since we do a TON of automation). As such, we tried for a while (to no avail) to get Web Deploy to work from the command line (tried for a while for us is measured in minutes not days, we don't have much patience for crappy tooling on our team).

So... we built our own.

It works like this - we have a very simple console app that we built in C# that looks at a particular blob storage account and tries to download a new blob from there if a new blob exists. In our case, we've named the container "w-deploy-newbits" and the blob name is "". This zip file is built on our build machine by doing a msbuild /t:Publish on our ccproj in order to build a deployable version of our website (_PublishedWebsites\WebRole in our build folder). We zip this file and upload it to the appropriate cloud location from the desktop as part of our build script (powershell with psake), and when the "NewBits" console app sees that new zip, it redeploys.

We have been using this technique for our profiling of our app (for performance) so that we can quickly make changes, redeploy, reprofile, and repeat the process. It has worked VERY well for this. We have no intention of using this for production releases or anything of that matter and would never recommend such a thing.

I'm going to try to make the code available in github, but it will probably take me some time to do so, as I need to remove anything sensitive to our own application setup and I'm really busy right now. However, if you want more details about how we did this, please feel free to contact me via comments or my email address.

Sunday, February 20, 2011

Setting up branches to always rebase in git

So, today at Harmony Hackathon, several people asked me to post the way to set up your branches in git to always rebase. I know this is a controversial thing in git, if you disagree with me on why you might want to rebase, I don't care. I like it and all I'm doing in this post is telling people how to do it if they want to. Don't do it if you're afraid of rebase, you don't want rebase, or you are afraid your friends will shun you for using rebases by default. Don't tell me if you don't like rebase, because I don't care ;)

Ok... I'm going to tell you how to set up rebase to ALWAYS rebase on ALL repos. If you don't want this for all repos, then you can do this on a per-repo basis by doing all the config without "--system". Also, you can use "--global" instead of "--system" if you want to ensure that other people that use your machine aren't affected by the setting (nobody else uses my machines, so I don't care and do all my config at the --system level).

So, to set up all "master" branches to do rebase by default - do the following:
git config --system branch.master.rebase true

To set up all "new" remote tracking branches to be created with rebase by default, do:
git config --system branch.autosetuprebase always

If you already have remote tracking branches, then I recommend you make sure you're current, delete the local branches, and recreate them (1.7.x does this automatically if you use the branch name to check out the remote branch, so make sure you're using Git 1.7.x or later for that hawtness (as darkxanthos would say)).

Resharper: Please indent my shit by 1000 miles, please! kthxbye

So... Today, while at the Harmony Hackathon, I took a few minutes of yak shaving time to figure out the location of the setting that had all of us at the hackathon cursing resharper from time to time. If you want to see an example of why we were cursing, see a screenshot below from visual studio for one of the methods we were working on.


Resharper has a setting that tells it to indent the crap out of array and object initializers, and the default is "please resharper, indent my shit off the screen so far to the right that I run out of scrollbar space if I have more than two nested lambdas or objects". Today we took to rectifying this problem in our configuration.

The setting is under formatting style / other / other / indent array, object and collection initializers. You can see it in the screenshot below. Uncheck it and stop bitching about resharper moving your shit 1000 miles to the right ;)