A picture of me

Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool for .NET applications.

Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.

The biggest difficulty I've had in the UK so far has been getting a bank account. I won't bore you with the details, but I'll summarise by saying that when your core business is to hold money for people so that you can leverage it to lend to other people, and your policies are so stupid that you can't hold money for people, it's no wonder you suffer in a credit crisis. This video captures my experience pretty well:

Feeling pretty helpless about the whole thing, I did some thinking about what my own bank would look like if I could open one. StovellBank would provide:

  • Ability to open an account (in a person or company name)
  • Ability to transfer funds electronically into and out of the account
  • A debit card

A small fee would be charged for holding the account. Balances wouldn't be allowed to drop below 0, so no credit facility is needed. Cheques, handing out cash and branches are all a thing of the past and wouldn't be necessary in StovellBank.

StovellBank wouldn't provide any form of credit or lending, and wouldn't leverage the deposited funds in any way, so there would be no fractional reserve lending nor the need to keep tight control over reserves. All money would sit in an interest bearing account of the Bank of England.

Founding a bank in the UK

The biggest hurdle here seems to be getting a sort code to participate in electronic transactions. Sort codes are allocated by the UK Payments Administration, and bank transfers are settled by the CHAPS group.

Where it all falls down is that to participate in CHAPS, you don't just sign up - you have to become a member. The membership criteria looks pretty daunting. Banks in the UK are also governed by the UK FSA. All in all, I get the feeling that creating my own bank would involve a lot of lawyer fees.

New Zealand

While opening a bank in the UK is difficult, opening your own bank in New Zealand might not be so hard, as long as you don't offer banking services to New Zealand residents.

This is probably a venture that go on the back burner.

A few weeks ago I wrote about my last day at Readify. Now that things have settled down it's time to share what I'm up to.

Two weeks ago I packed up my apartment in Brisbane and moved to London. Yes, my timing is impeccable. The move came about thanks to an opportunity to work with a nice small agile team, and it gives me a good chance to see the world at the same time.

Over the past year I've been thinking about the balance between personal and work time. I do a lot of coding in my personal time, mostly because the code I write at work, while interesting, is never as much fun as building my own ideas. I have come to the realisation that I'll be a lot happier if my "9-5" time could be spent building my own ideas, and it would free up little personal time.

So that's my goal for the next couple of years: to transition into working on my own ideas full time. I'm going to start with one idea that I'm very excited about, and stick with it until it either is successful, or it flops. They say most businesses fail in their first year, so the sooner I get the failure out of the way the better :)

Of course I need to earn a living in the mean time, so I've taken an independent contracting role in Canary Wharf. I'll be around some of the .NET-oriented user groups in London, so if you're in the neighbourhood I hope to meet you soon.

Tomorrow is a bitter-sweet day, as it will be my last day at Readify. I am leaving to start a new adventure, which I'll blog about next week.

Readify is unique in not only attracting good developers, but in giving them the opportunity to grow. Back in May I wrote about my fifth year at Readify and some of the things I've learned. I wouldn't be half the developer I am today if it weren't for Readify, and I am sincerely thankful for the opportunities Readify has given me.

Thanks to my colleagues and clients past and present for 5+ years of good experiences. I wouldn't work anywhere else in Australia.

A couple of weeks ago I opened Octopus to private beta, and now the betas are available for public download. As well as working on the technology, I've also spent a lot of time on the general business set up.

So far the business is operating at a loss of $840. The only way to go is up (or further down)!

Though I'm sure I'll grow tired of it, I've found the general admin side of things quite interesting so far. I actually went to sleep one night reading the business activity statement instructions guide. Adventures ahead.

Octopus downloads are now available from the OctopusDeploy website.

The drama around Windows 8 is getting a bit tiring. Now there's an Open Plea by Silverlight and WPF developers for Microsoft to make commitments as to the product future:

Three concrete steps or verbal commitments would assure us Silverlight and WPF developers that there is an integral, irreplaceable, and front-facing role to play in Windows 8 and into the future.

I grew up in a small town, about 5 hours from the nearest capital. For the first decade of my life, my parents owned a pet store. They worked hard and it grew to the largest pet store outside of the capital city, though we certainly weren't rich.

It was an industrial town, where the majority of people in the town got their income through the steelworks. One day talk started that the steel mill was going to be closed. As you can imagine, when most of the town expects to have no job tomorrow, they stop spending pretty quickly. Overnight, a huge number of businesses, including my parents, suffered real cash flow problems.

Many months later, the steel mill was sold, and it turned out the town didn't need to be so worried. But it was too long for most small business, who were forced to shut down and almost declare bankruptcy, including my parents. I remember that as one of the most stressful times of their lives.

I learnt a couple of lessons watching this:

  1. Speculation is bad for the economy. The steel mill never closed, but rumours that it might created so much uncertainty that many businesses were forced to close overnight.
  2. Putting all your eggs in one basket (in this case, opening a business in a town wholly dependent on one large business) is great when the going is good, but one day the rug will be pulled out from under you.

The rumours and speculation started the downfall, but my parents don't blame them - they recognise that they needed a backup plan.

Putting these lessons into context, here's what I think about the Windows 8 announcements:

  1. Microsoft's radio silence is creating some speculation that could put real people's jobs at risk.
  2. On the other hand, the people who's jobs are at risk are because they let themselves become wholly dependent on one stack, without a backup plan.
  3. Silverlight "chicken littles" are making the problem worse for themselves. By creating such a hullabaloo over the future of Silverlight, they're putting their own dumb selves out of business (you think your customers aren't looking at your Silverlight.net posts and deciding to go with Flash?) despite no announcements from Microsoft.

In politics I subscribe to the belief that the morals and values of the community should inform the government, not the other way around. When government is making decisions about what is good/not good for its citizens, it's described as a "nanny state".

In the Microsoft community, we seem to be in love with the "Nanny Stack". We expect Microsoft to decide whether the future is HTML or Silverlight. We expect Microsoft to have firm plans for the future, since most of us don't. And we blame Microsoft when they don't get their message 100% right.

As a community, we need to take more responsibility for our role in directing the future of the stack. Then we might learn not to put all of our eggs in one basket, and not let a little speculation destroy our businesses.

PS: Doesn't the Silverlight Open Plea remind you of the Save VB6 Petition?

Octopus Deploy is now a 1.0, available from OctopusDeploy.com.

A few weeks ago I posted some screenshots of an application I'm working on. A few people guessed, rightly, that it is a tool for automated deployment. Progress is going well, so I'd like to share some more details, and get your feedback.

Octopus is a automated deployment solution for .NET applications, powered by NuGet and designed for convention over configuration.

  • Deploy Web applications and Windows Services
  • Configure your applications automatically
  • Works inside your network or over the internet, securely
  • Track and report on how releases are promoted between environments

I'm working my way through the SecretGeek 25 things list, and writing plenty of code. My goal is to have Octopus ready for beta testing in a few weeks. If you'd be interested in taking Octopus for a spin, add your email address below. I promise to only send occasional updates as the beta program opens.

Subscribe to our mailing list

* indicates required

Where Octopus fits in

Imagine your development team has been charged with building an intranet web solution. The solution consists of:

  • An ASP.NET MVC web site
  • A SQL Server database
  • A Windows Service for performing some long-running tasks

The team are working iteratively. They check code into source control, and the build server picks up the code, compiles it, and produces artefacts ready to be deployed. Now, someone has to figure out how to deploy it.

Every application has different deployment needs, but they are usually pretty similar:

  1. The CI server builds the code and products artefacts (Zip files, WebDeploy packages, MSI's, etc.)
  2. The artifacts are copied and extracted on the target server(s)
  3. Web/App.config settings and connection strings are updated
  4. Performance counters and event log entries are created
  5. IIS web sites are configured
  6. Windows Services are installed and started

Ideally, these deployment steps would be automated. Unfortunately automating these deployments still takes a lot of manual work. Usually the solution is a cobbled together band-aid solution of PowerShell scripts, XPath queries, batch files and point-and-click tools.

Once you've cobbled together the PowerShell scripts and MSI packages for your application, zoom out, and look at the rest of your organization. How many other projects do you have? How many of them have automated deployment? How different is the deployment process for each application? Does it need to be this hard?

Octopus in action

Here's where Octopus fits in a typical organization:

Octopus in your enterprise

  1. Developers check code into source control
  2. The CI server (TeamCity, TFS, CCNet, whatever) compiles the code, and packages it into NuGet packages (I'll explain why below)
  3. The NuGet packages are exposed via a NuGet feed to Octopus
  4. A release manager commands Octopus to deploy a "release" of your application to an environment (staging, production, etc.)
  5. Octopus assembles all the NuGet packages, and pushes them to a "Tentacle", a small Windows Service that runs on your UAT/staging/production machines.
  6. The Tentacle agent deploys the NuGet package, and configures it (see below)

Concepts

Octopus understands a few simple concepts:

  • Package: A NuGet package containing the smallest unit of deployment for part of your solution (for example, YourApp.Web, YourApp.Database)
  • Project: A group of packages and deployment steps, for example, YourApp
  • Release: A set of packages, with versions, for a project. For example, YourApp release 1.5 contains packages YourApp.Web 1.5.3 and YourApp.Database 1.5.1
  • Machine: A computer running the Tentacle service, that you intend to deploy packages to
  • Environment: A collection of computers, such as Staging or Production

Most of these concepts should be pretty intuitive from the UI - my goal is to make the release process pleasurable. Check out some of the screenshots to see where it's going.

Environment definition in Octopus

Convention over configuration

Octopus was inspired by AppHarbor, which performs automated deployment of .NET applications from Git/Mercurial check-ins. AppHarbor has a very clever system for dealing with deployment:

  • If your VS solution has a Web project, it deploys it to an IIS site
  • If your web.config file has AppSettings with names matching variables you declare in the UI, they are automatically replaced

The end result is you never need to write automated deployment scripts for AppHarbor applications - it's automatic, because most applications work the same way.

Octopus shamelessly steals "borrows" these ideas, making enterprise application deployment as easy as cloud deployment on AppHarbor.

Conventions in Octopus include:

  1. Replacing appSettings and configurationStrings entries
  2. Updating the path of IIS websites if your package contains a web.config
  3. Running any System.Configuration.Install.Installers (for performance counters, event logs and Windows Services)
  4. Invoking a "Deploy.ps1" PowerShell script, if your package contains one

The cool thing is that all of these steps are run locally on the target server; you don't need to mess around with configuring WinRM or PowerShell Remoting.

NuGet packages

Instead of MSI's, Zip files or WebDeploy packages, Octopus standardizes on the NuGet package format. There are a few reasons for this:

  1. Packaging files into a NuGet package is extremely easy
  2. NuGet packages can be consumed via a feed, so other applications can easily query the available packages
  3. CI tools like TFS and TeamCity will soon have support to make publishing NuGet packages easy

At first this might seem like a strange use of NuGet. Currently, NuGet is mostly used for packaging DLL's and other files, mostly for open source components. Why use NuGet for packaging complete web applications or Windows Services?

If you spend time in the world of Linux however, you can see that package managers (like NuGet) have evolved beyond libraries. If you want to install Apache or MySQL on Linux, you'll use a package manager. Shouldn't we be able to do the same on Windows?

An aspect of this idea that I think is really interesting is the concept of an internal "enterprise software inventory". Imagine if every version of every internal application you built was available from a NuGet feed, instead of a mix of File Shares, TFS Drops and TeamCity artifacts?

Reports and metrics

Since Octopus takes a pretty holistic view of your projects, environments and releases, it can be used to answer some interesting questions:

  1. How long on average does it take Project A to get from Staging to Production?
  2. How often do Staging releases fail user acceptance testing before going to Production?
  3. Which version of Project A is in UAT right now?
  4. What were the release notes of version 1.4 of Project A?

The business

I've spent a lot of time over the past few years working on open source projects. Open source projects are hard. Getting contributors is tricky, and even when you do, they usually focus on contributing "fun" features rather than bug fixing and documentation. Unless your project is large enough to have a lot of momentum, it's hard to attract committed contributors to do the not-so-fun things.

I think Octopus stands a much bigger chance of succeeding if it has people committed to doing the not-so-fun things, producing a very useful, very high-quality product that you can trust to reliably deploy your software. For this reason (plus, well, greed :-)) Octopus is going to be a commercial product, and my first MicroISV. Even if it's a colossal commercial failure, I'm looking forward to the experience of product development.

Pricing

At this stage I expect Octopus will be priced using a TeamCity model - free enough that you can use it to deploy one project to your organization, but by the time you need to deploy your second project, you'll have gotten enough value from it that you won't mind sharing the love.

What do you think?

This is one of my longer blog posts, and I hope I've done a good job of explaining what Octopus is all about. I'd like feedback, good or bad, about the direction. Specifically:

  • What do you think about the conventions? Can you think of any others? I've documented them a little better on the knowledge base.
  • Is the system described above something that you could see yourself/your organization using?
  • How are automated releases currently done within your organization?
  • What additional reports/metrics would be useful?

So the rumors are true. Windows 8, from the bootloader to the composition engine, is going to be completely rewritten in HTML 5 and JavaScript:

Today, we also talked a bit about how developers will build apps for the new system. Windows 8 apps use the power of HTML5, tapping into the native capabilities of Windows using standard JavaScript and HTML to deliver new kinds of experiences. These new Windows 8 apps are full-screen and touch-optimized, and they easily integrate with the capabilities of the new Windows user interface. There’s much more to the platform, capabilities and tools than we showed today.

Mark my words: HTML is going to revolutionize the concept of the desktop. Nothing in the history of Windows has been this big, well, at least not since the last time HTML revolutionized the desktop:

Windows Desktop Gadgets contains mini-applications or Gadgets which are based on a combination of Script and HTML. They may be used to display information such as the system time and Internet-powered features such as RSS feeds, and to control external applications such as Windows Media Player. Gadgets can run "docked" in the sidebar or they can "float" anywhere on the desktop. It is also possible to run multiple instances of a gadget simultaneously.

Or the time before that:

Active Desktop was a feature of Microsoft Internet Explorer 4.0's optional Windows Desktop Update that allows the user to add HTML content to the desktop, along with some other features. This function was intended to be installed on the then-current Windows 95 operating system. It was also included in Windows 98 and later Windows operating systems until Windows Vista, where the feature was discontinued. This corresponded to version Internet Explorer 4.0 to 6.x, but not Internet Explorer 7.

Of course those were just interesting widgets, nothing special (I actually once had a 2-day consulting engagement to build a Windows Vista Gadget - it was THAT game changing). The version in Windows 8 is going to be FULL SCREEN and it will be used to build ENTIRE APPLICATIONS:

An HTML Application (HTA) is a Microsoft Windows program whose source code consists of HTML, Dynamic HTML, and one or more scripting languages supported by Internet Explorer, such as VBScript or JScript. The HTML is used to generate the user interface, and the scripting language is used for the program logic. An HTA executes without the constraints of the internet browser security model; in fact, it executes as a "fully trusted" application. The ability to execute HTAs was introduced to Microsoft Windows in 1999, along with the release of Microsoft Internet Explorer 5.

The topic of the month has already become "Is Silverlight/WPF dead?", which, let's face it, has been the topic of the month since .NET 3.0 shipped. It's quite possible that desktop HTML 5 applications could become another decision point on the platform decision flowchart, but will it really change the kinds of applications we're building today? Only time will tell.

(I'm curious to know whether Apple desktop application developers constantly pontificate over the demise of Cocoa since WebKit was open sourced, and whether PhotoShop or Visual Studio will be rewritten as Vista Gadgets HTML 5 desktop experiences)

Here are a few screenshots from a little application I'm working on. Can you figure out what it does?

Environments

Environments

Environments

Sunday, 8th of May marks five years at Readify for me. This week I am reflecting on the things I have learnt and the experiences I have had. On the bus home tonight, I did some thinking about some of the things I've learned over the years.

  1. Communication, communication, communication
    I learned how important it is to keep my client/team up to date with what I'm up to. It's important to let them know when I am blocked, and also when I accomplish something. Communication is the only "hammer" that can truly solve any problem.
  2. Act on the voices in your head and cognitive dissonance.
    Sometimes I have a nagging feeling that the client misunderstood me, or that I am missing something, but I'm worried about bringing it up again or looking foolish. I learnt to act on that feeling.
  3. Set expectations, then, set them again
    Problems often arise when you and the client have different ideas in mind of what you're going to deliver, often because you both assumed the other knew. Working iteratively and using planning and review sessions really helps with this, but the process can't do it alone.
  4. Assume the best intentions
    Most people are trying to do the right thing, they just have different information and contexts. Instead of assuming the person you're working with is doing the "wrong" thing on purpose, I learnt to take time to talk to them and understand their motivations. 90% of the time I find they are doing the best they can, and I would have made the same choices in their shoes. Through understanding them I'll be able to develop a better working relationship.
  5. Respect the client
    I'm smart with computers, so I naturally assumed I must be smart at everything else. But I learned early on not to assume I know better than the client about (almost) anything. If I see a problem, I'll ask, but I try to always assume the client knows their business better than me.
  6. Delivery is the key to trust
    As a consultant, you work through influence, not control. For that you need trust. I learnt long ago that trust needs to be earned, and the best way to do that is by delivering. When there's a problem, I can't just wave my arms about and offer solutions and expect to be taken seriously. I learnt to roll up my sleeves, deliver something, and earn that trust. Once I have the trust, I can then start to improve things.
  7. Overtime is never the solution
    I once spent 6 months doing 12-14 hour days and working weekends for a client, on the assumption that all the hard work would be worth it. It wasn't. In fact, it was the wrong thing to do. The overtime validated to the client that it was OK to push people that hard, and my willingness to do it "for the greater good" probably hurt my team more than helped. I learned working long hours is never the answer. I haven't heard from the company since, so I doubt it was time appreciated. On the other hand, I get Christmas cards from a company in Adelaide that I worked for (for a shorter time), doing the standard 9-5, adding real value. I want more of those clients.
  8. When you don't know, say so
    It might sound bad, but it actually took me a few years to be comfortable with this. A lot of my self-confidence was tied up in the idea that I was an "expert" in my technology niche, and I felt uncomfortable admitting when I didn't know something that I should. As I've matured, I'm more comfortable answering with "I don't know".
  9. Ask for help
    Readify, from my perspective, has good support structures in place to help when I'm worried about something. Usually it's nothing (I've had good luck in that I've never really had a problem with a client), but I learned that it is better to make a mountain out of a molehill than to have said mountain fall on top of me :-)

Thanks to my colleagues at Readify, both past and present, and to the many clients I've been lucky enough to work for. You made the last five years very rewarding.