Rob Reynolds - The Fervent Coder : Git

Let’s Get Chocolatey! Kind of like apt-get for Windows

Rob Reynolds — Fri, 07 Oct 2011 12:32:28 GMT

“If only there was some way to quickly and silently install applications and tools on my windows machine.”

Chocolatey is kind of like an apt-get, but for Windows. It is a machine level package manager that is built on top of NuGet command line and the NuGet infrastructure. Jason Jarrett recently described it as the free/OSS windows app store. What that means for you is that you can install and update software (applications and tools) on your machine with a few keystrokes and chocolatey does the rest!

Just how easy is it to install an application? From the command line, PowerShell, or Package Manager Console in visual studio you can type something like:

cinst windirstat

and watch it download and silently install WinDirStat on your machine.

A picture is worth a thousand words in this case:

If you want to try a tool (something that doesn’t actually install on your machine), try baretail, nodejs, or ravendb.

Creating Packages is also very simple: https://github.com/chocolatey/chocolatey/wiki/CreatePackages

Below is all that is required to install WinDirStat on your machine.

Install-ChocolateyPackage 'windirstat' 'exe' '/S' 'http://windirstat.info/wds_current_setup.exe'

Include chocolatey in your development environment setup! https://github.com/chocolatey/chocolatey/wiki/DevelopmentEnvironmentSetup Check out a living example - https://github.com/davidalpert/nuserve#readme

FAQ

What can I do with chocolatey? Since it uses PowerShell, you can do nearly anything you can do with .NET. Install applications, download tools and put them on the path, set up contributors machines for hacking on your code, install powershell commands, etc. Your imagination is the limit!

What’s your best example of the power of chocolatey? One line Ruby DevKit install. Seriously. http://groups.google.com/group/rubyinstaller/browse_thread/thread/8245c53f990d1ea6

I’m convinced! How do I install chocolatey? We try to make that simple as well. Open powershell, make sure execution policy is unrestricted (Set-ExecutionPolicy Unrestricted), and paste

iex ((new-object net.webclient).DownloadString("http://bit.ly/psChocInstall"))

I have included tools (executables) in my nuget.org packages, like Statlight and Fubu. Can I use chocolatey to “install” them? Yes, just call install like normal, it will check chocolatey.org first and then nuget.org. If it finds an executable in the package, it will automatically put it on the path.

How is chocolatey different from other windows machine package managers? It has PowerShell instructions for how to download native installers from the distribution source and install applications on your machine. It uses PowerShell so you can give it any instruction you want for install and configuration. It automatically makes batch command file links for executables you have included in your package or have downloaded to the package directory with the PowerShell script.

Is chocolatey awesome? I’m biased, but YES!

Is chocolatey version 1? Not yet, we have a few things going into the roadmap and enhancements being logged: https://github.com/chocolatey/chocolatey/issues

I’m not convinced, where do I find more information? I’ve listed quite a few resources below. I am likely missing some.

References

http://chocolatey.org/

https://github.com/chocolatey/chocolatey/wiki

http://groups.google.com/group/chocolatey

http://twitter.com/chocolateynuget

Videos

Chocolatey In Action (11 apps/tools in less than 7 minutes!): http://www.youtube.com/watch?v=N-hWOUL8roU

Create a Chocolatey Package: http://www.youtube.com/watch?v=Wt_unjS_SUo

Blog Posts

This dates all the way back to March 2011. Chocolatey has been actively worked on for awhile…

http://nuget.codeplex.com/discussions/251435

http://nuget.codeplex.com/discussions/257341

http://chrisortman.wordpress.com/2011/04/01/getting-started-with-chocolatey/

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/chocolatey-apt-get-for-windows

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/getting-chocolatey-to-work-when

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/chocolatey-gui

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/making-a-chocolatey-package

http://www.counity.at/blog/archives/253

http://www.xavierdecoster.com/post/2011/09/30/An-overview-of-the-NuGet-ecosystem.aspx

http://blog.codiceplastico.com/melkio/index.php/2011/10/06/chocolatey-un-package-manager-per-windows/

http://elegantcode.com/2011/10/05/chocolatey-the-free-and-open-source-windows-app-store

AppHarbor - Azure Done Right AKA Heroku for .NET

Rob Reynolds — Wed, 16 Feb 2011 12:49:23 GMT

Easy and Instant deployments and instant scale for .NET?

Awhile back a few of us were looking at Ruby Gems as the answer to package management for .NET. The gems platform supported the concept of DLLs as packages although some changes would have needed to happen to have long term use for the entire community. From that we formed a partnership with some folks at Microsoft to make v2 into something that would meet wider adoption across the community, which people now call NuGet. So now we have the concept of package management. What comes next?

Heroku

Instant deployments and instant scaling. Stupid simple API. This is Heroku. It doesn’t sound like much, but when you think of how fast you can go from an idea to having someone else tinker with it, you can start to see its power. In literally seconds you can be looking at your rails application deployed and online. Then when you are ready to scale, you can do that. This is power. Some may call this “cloud-computing” or PaaS (Platform as a Service).

I first ran into Heroku back in July when I met Nick of RubyGems.org. At the time there was no alternative in the .NET-o-sphere. I don’t count Windows Azure, mostly because it is not simple and I don’t believe there is a free version. Heroku itself would not lend itself well to .NET due to the nature of platforms and each language’s specific needs (solution stack). So I tucked the idea in the back of my head and moved on.

AppHarbor Enters The Scene

I’m not sure when I first heard about AppHarbor as a possible .NET version of Heroku. It may have been in November, but I didn’t actually try it until January. I was instantly hooked. AppHarbor is awesome! It still has a ways to go to be considered Heroku for .NET, but it already has a growing community. I created a video series (at the bottom of this post) that really highlights how fast you can get a product onto the web and really shows the power and simplicity of AppHarbor.

Deploying is as simple as a git/hg push to appharbor. From there they build your code, run any unit tests you have and deploy it if everything succeeds. The screen on the right shows a simple and elegant UI to getting things done.

The folks at AppHarbor graciously gave me a limited number of invites to hand out. If you are itching to try AppHarbor then navigate to: https://appharbor.com/account/new?inviteCode=ferventcoder

After playing with it, send feedback if you want more features. Go vote up two features I want that will make it more like Heroku.

Disclaimer: I am in no way affiliated with AppHarbor and have not received any funds or favors from anyone at AppHarbor. I just think it is awesome and I want others to know about it.

From Zero To Deployed in 15 Minutes (Or Less)

Now I have a challenge for you. I created a video series showing how fast I could go from nothing to a deployed application. It could have been from Zero to Deployed in Less than 5 minutes, but I wanted to show you the tools a little more and give you an opportunity to beat my time.

And that’s the challenge. Beat my time and show it in a video response. The video series is below (at least one of the videos has to be watched on YouTube). The person with the best time by March 15th @ 11:59PM CST will receive a prize.

Ground rules:

.NET Application with a valid database connection
Start from Zero
Deployed with AppHarbor or an alternative
A timer displayed in the video that runs during the entire process
Video response published on YouTube or acceptable alternative
Video(s) must be published by March 15th at 11:59PM CST.
Either post the link here as a comment or on YouTube as a response (also by 11:59PM CST March 15th)

From Zero To Deployed In 15 Minutes (Or Less) Part 1

From Zero To Deployed In 15 Minutes (Or Less) Part 2

From Zero To Deployed In 15 Minutes (Or Less) Part 3

Two Major Milestones for RoundhousE and UppercuT

Rob Reynolds — Fri, 01 Jan 2010 21:04:21 GMT

This last year I had a focus to get more involved in Open Source (OSS). The year before I had been involved a little by submitting a patch here and there, but 2009 was a big year for me in OSS. I now manage 4 open source projects that have solved a need for me and others. Coming up on the end of the year it was important for me to get some final touches into at least two projects to finish out the year.

UppercuT

UppercuT (UC), for those of you who have never heard of it, is an automated build tool that uses conventions to build your code. That means that you can have a professional build for most projects out of the box within 3 minutes! You drop it into a project, update a simple configuration and you’re done. It is also extendable (to the point of steps being completely replaced) so it’s very powerful. The goals we had for UC when we started it are that it’s insanely easy to use, easy to upgrade your builds, and easy to extend. It has met all of those goals and has some features that other build tools do not have (versioning out of the box and templating for configurations, documents, sql, deployment files, etc to name a couple). Check it out at http://projectuppercut.org.

So what milestone did we finish for UC? When the project started, there were plans for support for multiple types of source control for versioning the assemblies. We supported Subversion (SVN) from the beginning, but the priority for other types was lower. I’m pleased to announce that in the last two months we’ve added both TFS and GIT. The GIT one is a little more interesting. It follows what is suggested for versioning by Chris Ortman, GitFu and in the Git documentation. We also go the extra mile to show the SHA1 as well so you could theoretically get to that version.

How easy is it to do versioning with Git? Assuming you have a git repository, you crack open the configuration and change your source control to git:

If you’ve used UppercuT in the past or have been dying to try it out, set a goal to look at the latest verion this year before February.

RoundhousE

RoundhousE (RH), for those of you who have not heard of it, is a database migrations tool that uses SQL Scripts. RH is kind of like Tarantino. We had originally wanted to contribute our ideas to Tarantino, but some of the goals for the two didn’t line up nicely so RoundhousE was born. RoundhousE runs update scripts (the goal is DDL/DML only), but it also looks for other scripts in other folders (like functions, views, and sprocs). The reasoning for the separation is so that versioning and seeing version history is much cleaner in source control. RH also versions databases the way you want. We prefer to version our databases based on source control, but it is extendable to be versioned in any way (or not at all). RH has an MSBuild task, a NAnt task, but most importantly, a command line console (rh.exe). Everything is configurable (including the version and scripts run tables). Check it out at http://projectroundhouse.org. RH has quite an extensive roadmap for where it is going (we are moving it to be a total migration package, not just a migration runner).

So what milestone did we finish for RH? Making RH environment aware so you can execute environment specific scripts. Why would you want to do that? What if you wanted to insert a bunch of test data into your database but didn’t want that to get into production? What if you want to grant permissions to different users in different environments?

Here I have a set of permissions scripts. Notice they are environment specific.

Notice also that they have two things. They have “.ENV.” in the name to let RH know they are environment scripts. Then they also have the name of the specific environment (LOCAL, TEST) they should be run in. By the way, If you use UC and templating, you only maintain one file in source control and the file per environment is generated at build time (I digress). So we have some environment files and now I run RH to migrate my database.

We can see from the log notes below that it only runs the LOCAL environment script in the LOCAL environment.

LOCAL.GrantRobDataReaderDataWriterPermissions.ENV.sql is an environment file. We are in the LOCAL environment. This will run based on this check.
Running LOCAL.GrantRobDataReaderDataWriterPermissions.ENV.sql on (local) - TestRoundhousE.
TEST.GrantRobDataReaderDataWriterPermissions.ENV.sql is an environment file. We are in the LOCAL environment. This will NOT run based on this check.

And to be sure, let’s take a peek in the database:

If you’ve looked at RoundhousE in the past or haven’t yet looked at it, it’s worth downloading and running the sample to see what it can do.

By the way, you’ve probably noticed that have a definite theme with our developer automation tool suite (WarmuP, UppercuT, RoundhousE, DropkicK, HeadlocK, and SidePOP). We are still not solid on the library name, but pretty close. Each of the tools are designed to be enjoyable to use and free. We respond to inquiries and fix problems quickly. Once we have a name for the library, we may offer enterprise support for those that would require that.