It is quite obvious that all these continuous delivery and deployment automation tools are very good fit for organizations that develop software for themselves, either for internal use or meant to be published in software-as-a-service way. It is not so when it comes to an ISV, which is a Microsoft’s name for a company that uses their tools and platforms to develop custom software for other organizations. I work for Infusion which is more-or-less this kind of company. Big part of our business is developing custom software. We have quite a lot of clients and each engagement is different, also in terms of the responsibilities around deployment and hosting the app. Possible scenarios range from just passing the code (not very frequent), through passing binaries and assisting in production deployment as far as to maintaining the whole infrastructure and taking care of deployments and maintenance on behalf of the client. Clearly, there is no standard way of doing things at Infusion (which is of course good).

One to rule them all

On the other hand, there is a huge need to bring some sanity into the release process. We can’t just reinvent the wheel every single time we approach the go-live date. As part of an initiative aimed to standardize the release process we’ve been evaluating multiple products. One of them is OctopusDeploy. I had a pleasure working with Octopus few times before so I have full confidence in the product. What I want now is to confirm that is can be used in our ISV scenario. The first step was coming out with the following diagram:

Continuous Delivery ISV


The left part of the picture is our ISV. There is a developer there who commits to the source code repository. Then, a CI server (likely to be TeamCity) builds to code and runs the unit tests in the process called Commit Stage in continuous delivery lingo. The Commit Stage is designed to provide short feedback loop to the developers so only the fastest (no DB or any external access) tests can be run as part of it. If this stage succeeds, the second one kicks in where TC asks Octopus to deploy the code to the integration environment. Depending on the concrete scenario, it might be either a single integration tests assembly or a complete application along with some kind of test scripts. Bottom line is, we execute integration tests in this environment rather than on CI server. It allows us to more closely mimic real-world scenarios and also frees up the CI agent when the lengthy tests are being executed.

Human factor

When tests are done, the result file (an XML) is uploaded and imported into TeamCity. If the results are good, TC kicks off another job that asks Octopus to deploy the app to the internal QA environment where our lovely QA specialists can play with it a bit. Whenever necessary we can easily add more environments/test types to the process (such as performance tests, usability tests) but in most of our projects these two environments should be enough. After the tests are done, the QA engineer can mark the particular build as OK, allowing the Team Lead or the Project Manager to publish the build package to the customer.

Crossing the gap

The publishing format used is NuGet (which is a flavour of Open Packaging Conventions, OPC). In order to achieve desired level of security, NuGet packages are being digitally signed by the build server with our company’s certificate. Although signing is not supported by NuGet, it does not interfere with it in any way. Published packages are transferred to customer’s NuGet repository from which customer’s staff can deploy them to either UAT or production environments.


The deployment process is shared between all the environments on both sides (our ISV and customer) to ensure flawless deployments to production. The process is defined in Octopus and can be synchronized between ISV and customer’s Octopus instance using its great REST API.

Bright future?

Although we are still in the early stages of the implementation, it looks like this process can be without major modifications used to deploy any kind of web application we do (on-premise, Azure-hosted and SharePoint). The key to the success in our initiative is the ability to convince our customers to installing Octopus on their infrastructure. Luckily Octopus has a very thorough documentation with regards to security features it includes that can be used to dispel customer’s fears of automated deployment. The other important thing is the fact that octopus is free for small installations so the initial cost for the customer is close to zero making the entry barrier smaller. We hope that as soon as our customers start using it, they will love it and will include it as first-class citizen in their IT infrastructure.

In the ideal world (for us, an ISV) each our customer maintains their own instance of Octopus along with their environment configuration and release process (e.g. UAT, staging, production) and we agree on standard way of publishing packages and synchronizing the deployment process.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)