Posts tagged:   Architecture 

There are some compelling reasons to use multiple Octopus Servers. In Octopus Deploy 4.0 we want to add first-class support for these scenarios.

Snapshots have been a feature of Octopus since 2012, and they help to ensure that deployment processes are consistent for a given release. In 2015 we added Channels, which appears to make snapshots obsolete. We're considering removing snapshots in 3.4.

18 months ago we switched from RavenDB to SQL Server, but we kept using SQL as if it were a document store. This post goes into some detail about how our database works.

Nano Server is an extremely small version of Windows Server. .NET Core is a small version of the .NET runtime. Together, I believe they are the future of how applications will run in production.

Octopus and Tentacle have always been built against .NET 4.0, but from Octopus 3.1 onwards we'll be building against .NET 4.5.

We recently made big changes to deployment targets and Azure cloud services in Octopus 3.0, and it turns out we got our design wrong. In 3.1, we'll be reverting to the 2.6-era way of deploying cloud services. This change will also affect the way we deploy Azure web apps.

Variables can be scoped to multiple values. What's the simplest way to score them?

In Octopus 3.0 we're adding a data migration tool. This post explains some of the scenarios where we think it will be useful.

Octopus: HA makes it possible to set up a high performance, reliable Octopus Deploy cluster. This post explains the architecture, and the kinds of scenarios it does and doesn't support.