CI/CD refers to continuous integration and continuous deployment. A typical CI/CD pipeline involves a continuous integration server (or build server) and a continuous deployment server, such as Octopus.
The continuous integration/build server compiles your code into one or more artifacts and runs tests against them.
The continuous deployment server takes the compiled artifacts from a successful build and deploys them through the deployment pipeline which might consist of the following environments, Dev, Test, and Production.
A typical CI/CD pipeline
A typical CI/CD pipeline with Octopus Deploy looks like this:
- A developer commits code changes to version control.
- The build server detects a change and performs the continuous integration build, which includes resolving dependencies, running unit tests, packaging the software and making it available in a package repository.
- Octopus Deploy is notified of a new artifact in the package repository and executes the deployment process to create a release that is deployed to the Dev environment.
- When a team member (perhaps a tester) wants to see what is in a particular release, they use Octopus to manually deploy a release to the Test environment.
- When the team is satisfied with the quality of the release and they are ready for it to go to production, they use Octopus to promote the release from the Test environment to the Production environment.
To learn more on how to package your software using your CI server of choice and deploy software to your specific deployment targets, please see our End-to-End CI/CD pipeline tutorial.
Octopus build server integrations
The following tools are available to integrate your continuous integration/build server with Octopus Deploy:
- Azure DevOps & Team Foundation Server
- BitBucket Pipelines
- Continua CI
- Github Actions
It is often useful to have information flow from your build server to be associated with packages, releases, and deployments in Octopus.
The build information is associated with a package and includes:
- Build URL: A link to the build which produced the package.
- Commits: Details of the source commits related to the build.
- Issues: Issue references parsed from the commit messages.
Passing build information to Octopus
Build information is passed to Octopus as a file using a custom format. The recommended way to supply the build information is to add the Build Information step from the Octopus Deploy plugin to your build server.
Check our downloads page for our latest build server plugins.
Build information is independent from the packages that it relates to. You can pass build information to Octopus before the packages have been pushed to either the built-in repository or an external feed.
Build information step
The TeamCity version of the Build Information step is shown below.
The Verbose logging option can be used to include more detail in the build logs. This includes a complete output of all of the build information being passed to Octopus, which can be useful when troubleshooting.
Viewing build information
2019.10.0, the build information for a package can be viewed by navigating to Library ➜ Build Information
The build information for a package can be viewed on any release which contains the package.
For packages pushed to the Octopus built-in repository, the build information can also be viewed in the package version details by navigating to Library ➜ Packages and selecting the package.
Commit messages and deep links may not be shown if an unsupported
VcsType is passed to Octopus as part of the build information call. Currently we support values of
TFVC (TFS / Azure DevOps).
SVN (Subversion) is not supported.
Using build information in release notes
See the system variable documentation for the available variables.
Using build information in deployments
Package build information associated with a release will be also captured in deployments of the release.
Need support? We're here to help.