Manage CI/CD

You can configure continuous integration (CI) and continuous deployment (CD) for individual services and jobs, or create combinations of build services with deployment services and jobs depending on your requirements.

Continuous integration can be configured to build each commit, or you can build from specific branches or pull requests. You can also configure advanced settings to only build when specific files or directories are updated, or to skip builds with certain commit messages.

Continuous deployment can be enabled to always roll out or run the latest build.

Using CI/CD with path rules and ignore flags allows you to manage your build and deployment workflow from development to production, automatically building and deploying only where desired and retaining manual control where needed.

For example, you could configure a build service with path rules, linked to a CD-enabled deployment service, to automatically build and deploy your frontend to preview changes immediately. You can then manually build and deploy your backend only when required. Add commit message ignore flags to skip building minor changes, and automatically build and deploy all your microservices when you want to test the pull request for your next release.

Continuous integration can be enabled on combined services, build services, and jobs that build from a repository as a source.

You can enable and disable CI using the toggle in the header of the service or job.

CI on a combined service

You can enable CI on a combined service so that any new commits to the linked repository branch will be built automatically. If you also enable CD, every new commit to the branch will be automatically built and deployed.

CI on a build service

You can enable CI on a build service to build any new commits to branches or pull requests that the service is configured to monitor.

You can combine this build service with one or more deployment services to create an effective workflow. For example, your build service could build both your development and production branches, and a deployment service with CD enabled could automatically deploy the latest development build. Another deployment service with CD disabled could then be used to manually deploy stable production builds when you are ready to release. You can also use the build service as a source for jobs.

CI on a job

If you create a job that has version control as the image source, you can configure CI and other build settings within the job. If you enable CI on a job, it will always build the latest commit to the linked branch. If you also enable CD, the job will use the latest build when a run is triggered.

You can use path rules to trigger a build only when specific parts of your repository have been modified. You can either ignore directories or files containing code that you don't want to build in a specific job or service, or allow only the directories or files containing code that you want to build for a particular service or job.

Path rules can be configured from the build options page of a job or service, in advanced build settings under build type.

You can use commit message ignore flags to stop builds being triggered if the commit message contains a specific string.

Commit message ignore flags can be configured from the build options page of a job or service, in advanced build settings under build type.

Continuous deployment can be enabled on combined services, deployment services, and jobs.

You can enable and disable CD using the toggle in the header of the service or job.

CD on a combined service

You can enable CD on a combined service so that it will always use the latest build from the service. If you have CI enabled, any commits that trigger a build will then be automatically deployed.

CD on a deployment service

You can enable CD on a deployment service to always use the latest available image from the source. If you're using a build service as source, this will trigger a redeployment with the latest build when one is completed successfully.

If you're deploying an image from a container registry, this will always deploy the image tagged latest when a container is started. This means you must roll out a restart of your service to redeploy the latest container image.

CD on a job

You can enable CD on a job so that it will always run using the latest available build or the container image tagged latest.

You can configure a job to run automatically when the source image is changed, if the job uses version control or a Northflank build service as the source. You can set this when creating the job, and change it from the job settings page. The following options are available:

• Never: the job will not automatically run when the image changes. The job will continue to run on a schedule, or when run manually, and the image deployed will be according to the CI/CD configuration
• CD & pipeline promotion: the job will be triggered to run if a build finishes and CD is enabled, or if an image is promoted to the job via a pipeline
• Always: the job will run every time the image is deployed via the UI, if a build finishes and CD is enabled, or if an image is promoted via a pipeline