nuget Update-Package with a filter
One of my biggest annoyances about nuget and powershell in general is the lack of universal support for unix like features such as pipe and grep.
Lets say you have a solution with multiple projects in and you want to update to the latest versions of your internal dependencies, you’d proabably do something like.
OctoChef - Abusing Octopus Deploy for Windows Server configuration Management
Unix has some great tools like chef to help you declaratively describe the configuration of your server. It means that you can almost guarantee the state of your servers and there’s no need to log on to each server and manually configure them, freeing up people to do more interesting things with their lives.
making the perfect cup of tea
George Orwell - A Nice Cup of Tea Essay is often refered to. However, since the original essay was written the invention of the tea bag has changed the way most people in the England make a mug of ‘builders’ tea. This is how I make the perfect cup of tea.
HOWTO: Deploy mono web applications with capistrano-mono-deploy
I’ve recently been working on a capistrano gem to help with mono deployments. I’ve had a bit of experience trying to get capistrano to work with non-rails environments, basically it can be a bit of pain if you’re not sure what you’re doing. Also most of the beginners tutorials are aimed at people developing Ruby on Rails. So I though I’d create a gem and provide a little how to. The gem is called capistrano-mono-deploy. This is how you can use it to deploy a simple web application to a Linux machine. In this example I’ll be using the excellent ServiceStack for the web application and xsp4 to host the it. You can find all the code on my github account.
I’m running Ubuntu 12.10 on my server and am using Mono 22.214.171.124 which was installed from the package repository using apt-get
Deploying ServiceStack to debian using capistrano hosted using nginx and fastcgi
Over the last month we’ve started using ServiceStack for a couple of our api endpoints. We’re hosting these projects on a debian squeeze vm using nginx and mono. We ran into various problems along the way. Here’s a breakdown of what we found and how we solved the issues we ran into. Hopefully you’ll find this useful.
We’re using version 2.11.3. There are various bug fixes compared to the version that comes with squeeze. Namely, problems with min pool size specified in a connection string. Rule of thumb, if there’s a bug in mono then get the latest stable!
We’re using nginx and fastcgi to host the application. This has made life easier for automated deployments as we can just specify the socket file based on the incoming host header. There’s a discussion about what’s the best way to host ServiceStack on Linux at stackoverflow. Our nginx config looks like this:
When we deploy the application we nohup the monoservice from capistrano
fqdn is the fully qualified domain name, i.e. the url you are requesting from
latest_release is the directory where the web.config is located.
To get the files onto the server using capistrano we followed the standard deploy recipe. In our set up we differ from the norm in that we have a separate deployment repository form the application. This allows us re-deploy without re-building the whole application. Currently we use Teamcity to package up the application. We then unzip the packaged application into a directory inside the deployment repository.
We use deploy_via copy to get everything on the server. This means you need to have some authorized_keys setup on your server. We store our ssh keys in the git repository and pull all the keys into capistrano like this:
ssh_options[:keys] = Dir["./ssh/*id_rsa"] ###No downtime during deployments ... almost Most people deal with deployment downtime using a load balancer. Something like take server out of rotation, update the server, bring it back in. The problem with this is it's slow and you need to wait for server to finish what it's doing. Also in our application we can have long running background tasks (up to 1000ms). So we didn't want to kill those of when we deployed. So we decided to take advantage of a rather nice feature of using sockets. When you start fastcgi using a socket it gets a handle to the file. This means that you can move the file! Meaning that you can have a long running process carry on whilst you move you new site into production, leaving that long running task running on the old code to finish. Amazing! This is what we have so far: <script src="https://gist.github.com/3760738.js"> </script> There's room for improvement feedback appreciated.