Creating a release for a single service / component
This tutorial demonstrates how to semantically version a single component before it is deployed to an environment. The component can be any artifact that is deployed to an environment such as a JAR/WAR file or a Docker image. In a broader end-to-end context, the
release job usually should be an
IN for a deploy job as shown below:
In general, creating releases helps you version your component and keep track of what is included in each release. However, this step is also optional, so you could choose to directly connect your
manifest job to
- First, you will want to create a version resource in your
resources: # Release version - name: my-version type: version seed: versionName: "1.0.0"
Set the starting point of your version in the versionName field. The
release job defined in the next step will use the versionName as the seed and increment it whenever it is triggered.
- Next, add a
releasejob to your
shippable.ymlfile. The snippet below also shows sample configuration for the input manifest job:
jobs: # Manifest job - name: my-manifest type: manifest steps: - IN: my-image - IN: my-image-dockerOptions # Release job - name: my-release type: release bump: beta steps: - IN: my-version - IN: my-manifest
nameshould be an easy to remember text string. This will appear in the visualization of this job in the SPOG.
typeis always set to release
- The manifest job and version resource are inputs, i.e. specified in the
bumptag specifies how the release version will be incremented each time the release job runs. More on incrementing versions is described in our tutorial for bumping release versions.
Add your project to your subscription as a syncRepo and run the manifest and release jobs. Your pipeline should now look like this -
We have a working sample for the scenario described here. Instructions to run this sample are in the README.md file.
Sample repository: devops-recipes/release-single-component.
The scenario in our sample project covers the following steps:
- Set up your CI workflow, which pushes a Docker image to Docker Hub.
- Every time the image is updated, a manifest job updates the manifest.
- The release job will version your manifest with semantic versioning.
- This will trigger a deploy job which will deploy your versioned component to a target endpoint of your choice. Read more on deployments.
Improve this page
We really appreciate your help in improving our documentation. If you find any problems with this page, please do not hesitate to reach out at firstname.lastname@example.org or open a support issue. You can also send us a pull request to the docs repository.