More Flexible Deployment Pipelines

Codeship News

Keeping your deployment environments during feature development manually up to date is a time consuming and tedious process. Each time you push changes you have to make sure to update the corresponding environments and communicate that to your team members involved.

Automating your deployment to those environments makes that as seamless as possible and reduces the time to make change. The faster you can make the latest changes available and accessible to everyone involved in the feature life cycle, the sooner you get feedback and improve on it.

Getting Started with Wildcard Deployment Pipelines

We are happy to introduce wildcard deployments that let you configure deployment pipelines for branches that start with a certain prefix. Configuring these “wildcard” pipelines allows you to set up flexible deployment workflows that fit your team’s needs. If you first want to become familiar with how Codeship supports Deployment Pipelines in general read more about it in this Deployment Pipelines article in our docs.

Wildcard Deployment Pipelines Config on Codeship

You are able to configure these pipelines on your deployment page in your project settings. Check out the feature documentation for further details (Wildcard Deployment Pipelines on Codeship).

Being able to deploy branches that start with a certain prefix enables much more flexible deployment workflows.

  • Use Gitflow to deploy “release” branches to your staging environment.
  • Easily setup your “feature” branches to be deployed to a QA environment.
  • Don’t to want deploy each time a code comes on master but, instead, when you create a release tag? Configure your deployment pipeline to deploy each release tag to the same application.
  • You want to create development environments for each engineer? Configure Codeship to automatically deploy branches of each of their environments.

These more flexible configurations give you the ability to adapt your deployment workflow to your needs. Flexibility means your applications are easier to deploy and much more accessible to your whole team. Faster deployments mean quicker feedback and generating faster value for your users.

Sign up and automate your deployments – get started here.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.



We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • Curious about that release tag deployment. I don’t understand, how would we have to configure the pipeline for that?

    • Alex Tacho

      If you push tags to your remote repository we trigger a build for that tag as well. The tag behaves like a branch. So if you tag releases with release-1.2 and add a wildcard deployment pipeline for “release” you are able to deploy those tagged commits.

      • Awesome, thanks for the explanation. We will try it out!

        • Alex Tacho

          You are very welcome. If you have any further questions you can always contact us in app or send an email to alex [at] codeship.com

      • Franz Josef Kaiser

        Would be nice to have some more in depth and tutorial like info in the article to fill such gaps. The feature itself: Awesome.

  • cruisercohen

    I’m not seeing new builds kicked off when I push a tag. The tag based deployment pipeline sounds pretty useful though so hoping to get it working.

    • Alex Tacho

      Can you send an in app support request, so that we can check that. Thanks.

      • cruisercohen

        Sent. Thanks!