Reliable and Automatic Multi-Target Deployment

Multi-target deployment can feel tedious as you deploy the same code over and over to multiple clouds and environments — and none of them in the same way. With an automatic multi-target deployment tool, on the other hand, you do the work once and deliver your code everywhere it needs to be.

Armory provides an easy-to-use tool for DevOps and release engineers to gain safe, reliable, and automatic multi-target deployments. This article discusses how Armory (the next evolution of Spinnaker) helps streamline your pipeline with integrations and automation.

What Is Multi-Target Deployment?

A target is a destination where developers apply configuration or run code after completing a delivery process. An example of a target is a database or a production environment.

Multi-target deployment may be multi-cloud deployment, which deploys the same application across multiple cloud vendors, or deployment into different environments within a single cloud. Or, it may be a combination of multi-cloud and multi-environment.

Multi-target deployment may involve different ways to run the same application. In some cases, developers must deploy a single application to bare metal servers, VMs, and containers. They might also have multiple sub-targets.

For example, a corporate mobile app created with a cross-platform toolkit like React Native or Flutter needs separately built targets for creating iOS and Android versions. This dramatically increases the complexity of deployment and warrants the need for a platform to manage multi-target deployment more effectively.

Enter Armory and Spinnaker

Armory equips developers like you with the tools to automate multi-target deployments, allowing companies to innovate faster, ship better software faster, and exploit the benefits of multi-target deployment more effectively.

Armory provides an enterprise tested reliable deployment product that has open source Spinnaker at its core. Spinnaker is one of the fastest-growing continuous delivery tools for deploying safely and continuously to cloud platforms like AWS, EKS, GCP, Kubernetes, and Azure, to name a few.

How Does Armory Achieve This?

Armory and Spinnaker combine to’s version of Spinnaker supports a wide range of cloud deployment environments from these cloud providers:

  • Google App Engine
  • Amazon Web Services
  • Microsoft Azure
  • Google Compute Engine
  • Cloud Foundry
  • Kubernetes
  • Oracle Cloud

Registering and configuring a cloud provider is the first step and is central to everything done within Armory. Here, developers define a server group, which is a single deployable artifact within Armory and a collection of instances of the running software. This includes EC2 instances, VM instances, and Kubernetes pods. The server group contains basic configuration settings about the application, such as the number of instances and scaling policies.

Once registered and fully configured with the cloud provider, you can create pipelines based on strategies. Pipelines are the main deployment components and are crucial to defining the deployment strategies. These pipelines are a sequence of stages used to represent a deployment workflow.

You can start pipelines manually or trigger them throughout the software development process by automatically activating events such as pushing code to GitHub, a successful build by Jenkins, a new Docker image hitting the registry, or completing a stage in another pipeline. You can configure these pipelines to emit notifications by email, Slack, HipChat, or SMS at various points during pipeline execution, such as pipeline start, completion, or failure.

You can use Armory as a single point to orchestrate deployments to multiple providers spanning multiple targets. This way, you don’t have to manage environments separately. This exponentially reduces the complexity often experienced with multi-target deployment.

Configuring Artifacts

An artifact is a remote deployable resource or an object that references an external resource. The external resource could be any of the following:

  • A code repository like GitHub: You can configure Armory to listen to code changes and activate a pipeline every time code is committed to the repository. Armory can pull the latest build and deploy it to a target environment.
  • An artifact repository like Amazon S3: A stage can directly read data from this repository.
  • A container registry, such as Docker Hub: Here, you must deploy software as a Docker image.

You can easily integrate these with Armory after registering the target cloud providers. You can configure Armory to listen to events to trigger pipelines and collect artifacts produced by builds in continuous external integration (CI) systems.

You can also fetch these artifacts using a URI. However, the URI usually isn’t enough and can omit important information about the resource. So, Armory provides an image bakery to help produce machine images.

Currently, Armory supports GitHub Actions and Jenkins.

Working With Pipelines

Pipelines are the critical workflow constructs used to manage deployments. They control how to deploy our application. A pipeline is a sequence of stages that you can combine in many ways to precisely define the functions for managing deployments. This makes pipelines flexible, consistent, and repeatable.

As mentioned before, when creating a new pipeline for a selected application, you must add stages to specify the actions that the pipeline performs. These stages break the pipeline into small, customizable blocks, each one of which serves a specific task. You link the blocks together to represent the whole continuous delivery process.

Types of Stages

You can add any number of stages to the pipeline and in any order preferrable to suit a business’s needs. These stages fall into four broad categories.


The stages operate on the underlying cloud infrastructure, and you implement them for every cloud provider where applicable. They are responsible for creating, updating, or deleting resources. This provides an efficient and consistent way to deploy to multiple targets and provides a seamless experience. This applies to creating AMIs or Docker images that you can bake, tag, and associate with a specific server group.

External Systems Integrations

Armory can interact with CI systems and provides integrations to enable users to chain together logic performed on external systems other than Spinnaker. You can trigger pipelines with Jenkins or Travis CI. The Jenkins stage enables you to reuse existing functionality when migrating from Jenkins to Armory.


You can use testing stages to uncover issues related to fallback, latency, load limit, and performance degradation. You can also run functional tests using Jenkins.

Flow Control

With these stages, users can control the pipeline’s flow by making customizations that enable performing conditional logic. This allows human interaction for acknowledgment purposes, waiting for a specified amount of time, and the nesting of pipelines. This means you can run another pipeline from within the current pipeline.


When working with pipelines, it’s essential to know how to start them. As mentioned earlier, you can begin them manually or automatically using triggers. A pipeline can react to time-based triggers, which can be manual or a cron job. You can run manual triggers as needed or base cron triggers on the scheduling capabilities of cron jobs.

However, most of the time, you would want to start a pipeline based on events caused by other resources. These are known as event-based triggers. Some examples of event-based triggers are commits made to a Git repository, changes in a Google Cloud Storage bucket, or after a Jenkins job completes successfully.

You can also trigger pipelines programmatically by subscribing and listening to a pub/sub topic and pushing messages to the configured topic. To broadcast the status of these pipelines, Armory enables us to configure notifications for pipeline start, success, and failure.


Expressions give you a more advanced way to customize the pipeline further and provide more control by exposing the raw pipeline JSON. You can make decisions based on parameters passed into the pipeline or data coming from a trigger. You can set and access the values during the execution of the pipeline.

This is useful when deploying to multiple targets based on certain conditions so that you don’t build custom stages or extend existing ones to cover different cases.

Rollout Strategies

The last step of a pipeline is a rollout strategy which Armory provides out-of-the-box. Armory supports the red/black, rolling red/black, and canary strategies. You can use these strategies with providers such as Amazon EC2, Google Compute Engine, and Kubernetes.

Using Automated Canary Analysis

This is a deployment process in which you partially roll out a change and use the current deployment as a baseline to evaluate the quality of the new deployment. You can assess the quality using key metrics chosen when configuring the canary. Using these metrics in Armory enables you to ensure the releases are safe and reliable.


With Armory, companies can target multiple environments and cloud providers and seamlessly deploy them from a single user interface while following industry best practices. This is very important for rapid deployment since no time is spend customizing each environment.

Check out our videos to learn more about performing tasks in Spinnaker.

To learn more about Armory and how we can support your digital transformation, contact us.

If you’re interested in developing expert technical content that performs, let’s have a conversation today.



If you work in a tech space and aren’t sure if we cover you, hit the button below to get in touch with us. Tell us a little about your content goals or your project, and we’ll reach back within 2 business days. 

Share via
Copy link
Powered by Social Snap