Build vs. deployment. What's the difference?
Automated build servers like Jenkins, TeamCity, and Team Build are designed for continuous integration. They do this by providing a single place to verify the code a developer has committed compiles, that unit tests pass, and that it's safe for other developers to merge their changes. Practically speaking, they settle the age-old "it builds on my machine" debate by providing a consistent build environment.
Deploying software and building software are different:
- A build server runs an entire build sequentially on a single agent, but in a deployment there are usually many servers involved and some deployment steps need to happen in parallel.
- Builds embrace the "fail fast" principle. If a problem is encountered during a deployment, we often want to manually intervene, or skip the broken step and proceed with the rest of the deployment.
- Build server permission & auditing models aren't usually designed for release management.
The best engineering teams recognize that build and deployment are fundamentally different. There are some similarities - they both involve automation - but the architecture of a robust deployment system is different to that of a build server.
Read more about why build servers are different to deployment servers.
Why Octopus Deploy?
Most cloud platforms and build servers claim some kind of deployment capability. Octopus is unique because we focus on being world-class at deployments, and we do this by integrating well with all of the major build servers and clouds.
As a dedicated deployment automation server, Octopus Deploy has features not seen in any other deployment automation tool. Features like first-class multi-tenancy support, managing your SSL certificates, powerful built-in deployment steps that save you a ton of time, manual intervention, rich permissions and auditing, delta compression to reduce downtime during deployments, and a whole lot more.
Octopus completes your CI/CD pipeline
You already have a source control system and a build server. Octopus doesn't replace these, we turbocharge them. Let the build server focus on what it does best: compiling code and running tests. Octopus takes care of deploying and promoting releases between environments.
Getting started with Octopus Deploy is incredibly easy
Package your applications
Build and package your application as standard JARs or WARs and push them to the Octopus built-in repository. Octopus will deploy those packages directly to your application servers via SSH or Tentacle.
Define your deployment process once
This is your recipe for how your application will be deployed. Octopus comes with over 300+ built-in and community-contributed step templates for deploying just about anything. You can also add script steps that use Bash, Python, PowerShell, or manual intervention steps to acquire approval from product owners.
Every environment is different. Octopus takes care of your test and production configuration settings, stores your secrets securely, and automatically replaces values in your configuration files - no scripting needed.
Deploy and promote
Self-service deployments mean anyone on your team can deploy a release when they need to, or use permissions to control who can deploy to production. Octopus brings the deployment logs into a single central view, even as deployment steps run in parallel, so you'll always know what's happening.
Watch the dashboard
Tired of being asked what version of the app is in production today, or not sure if last night's test deployment was successful? The Octopus dashboard tells your team at a glance what's deployed where.
Consistency means production deployments that succeed
Production deployments are still the riskiest part of software development. If something goes wrong during deployment, the stakes are high: extended downtime, angry customers, and potential roll backs.
Solutions like Azure DevOps have a different deployment process for each environment, meaning the process that deploys the app to your test environment is not the same process as the one that promotes it to production. When you deploy to dev, do this. When you deploy to test, do that. Keeping them in sync requires a lot of copy and pasting.
Octopus has a unique model that is all about consistency. It's this consistency that makes deployments reliable. Octopus uses the same deployment process for each environment, using only variables and conditions to skip steps that are not required. With Octopus, the production deployment process is the same as the pre-production deployments, you're essentially testing the production deployment process every time you deploy to a test or dev environment. By the time you deploy to production, you've run that exact process a dozen times in your pre-production environment, so you are confident it works.
This core focus on consistency is everywhere in Octopus. We take a snapshot of your deployment process when you create a release, that way, if you change the deployment process later, you won't accidentally run the new, unproven process when you promote the release you've been testing all week into production. Multi-tenant deployments in Octopus are consistent even when you deploy the same application to thousands of end customers.
Over 400 deployment steps out of the box
Deploy just about anything without scripting, from Azure Functions to Windows Services. Send Slack notifications, notify monitoring tools of a deployment, upload files to your CDN, run a SQL script - Octopus probably has a deployment step for it. Octopus is used by over 20,000 companies, so many of these templates are contributed by our community. View the full list of templates in the community library.
Octopus Deploy is the only deployment server that makes it easy to deploy applications on behalf of many end customers.
Securely store and deploy X.509 certificates for your web sites, and be notified when they are due to expire.
Command line & REST API
The Octopus web UI is built over a REST API. Anything the UI does, you can do too.
Creating happy deployments at more than 25,000 companies, including:
We've been overhauling our internal infrastructure and back-end systems over the past month, including a move back to full @OctopusDeploy deployments; rediscovering how nice it is to have a platform-agnostic orchestrator that can deploy practically anything, anywhere ❤Nicholas Blumhardt