Release Notes
28 Nov 2023
Support for AWS Lambda
Armory CD-as-a-Service now supports deploying to AWS Lambda. Orchestrate your Lambda function release across multiple AWS Accounts, ensuring they are always tested in staging, then leverage canary deployments in production.
Learn more:
2023 Sept 29
Pipeline graph is now available when deploying to a single target
Certain functionality, such as trigger nodes and the ability to redeploy an old version, are only available on the pipeline graph. With this change these features are available when deploying to a single target.
2023 Sept 15
New on the deployment graph: Deployment triggers with source context
We’ve added a new element to the deployment graph called a Trigger Node which explains how a deployment was triggered by displaying the source system, initiating person, and trigger type. This allows anyone on the team to immediately know the source of a deployment, including who triggered it, and how it maps back to a pull request or commit.
When triggering from GitHub, additional source details will appear on the Trigger Node: PR title, PR number, commit SHA, branches, and in the event of a push tag trigger, the associated tag. Each element in the Source section is a deep link back to GitHub.
If context variables were passed with the trigger, they will appear in a Context Variables section on the Trigger Node.
Trigger Nodes will automatically show up on your deployment pipelines. Customers who have already configured a GitHub Action will need to adjust the workflow token permissions in their configuration to view the full set of Source Context information. This can be accomplished by adding a permissions block to your workflow, and adding a token to the GitHub action’s env block.
Refer to the updated documentation pages for more information:
permissions:
contents: read
pull-requests: read
statuses: read
# Add GH_TOKEN to env in the cli-deploy-action step
- name: Deploy
env:
GH_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
uses: armory/cli-deploy-action@main
2023 Aug 29
Connected clusters available as deploy targets in the wizard
Use already connected clusters to set up deployments for your new applications using the wizard. Earlier, using the wizard to set up new applications forced you to install a new Remote Network Agent (RNA), which was not ideal if you already had your cluster connected, leaving you with the option of creating a new deployment file using our docs. CD-as-a-Service enables you to select an already connected cluster when setting up a new application via the wizard and easily onboard new applications. Additionally, we have streamlined RNA installation experience, making it easier to choose between various installation options. The updated RNA install experience is currently live within CD-as-a-Service setup.
2023 Aug 04
Developer Hub is live - central locations for all the CD-as-a-Service resources
The new Developer Hub provides a central location for all the resources you need to get started with Armory CD-as-a-Service. The hub includes links to documentation, tutorials and release notes.
Additionally, the CD-as-a-Service documentation for has been revamped with new and updated content to help you get started with Armory CD-as-a-Service. Navigation is now structured to make it easier for you to find the relevant content.
2023 July 21
CLI v1.15.3 returns exit code 3 when there is an ongoing deployment
The Armory CLI now returns exit code 3 when there is an ongoing deployment. CD-as-a-Service allows only 1 deployment to be in progress for an application. Previously, the Armory CLI would print an error message for ongoing deployments, but would return with an exit code 0. This made it harder to determine if the deployment was successfully started or rejected because one was already in progress. We have improved the behavior, as well as improved the error message formatting.
2023 July 14
Can now recreate the deployment object when deploying
Historically Armory CD-as-a-Service has managed replica sets when deploying a Deployment object, and once deployment was complete there was no Deployment object in cluster. With this change we can now deploy the deployment object as well so that existing runbooks (e.g. restarting a deployment object) can be run on it if desired.
To enable this functionality<
Add the following configuration block to your application’s deploy.yml:
deploymentConfig:
keepDeploymentObject: true
2023 June 05
View Kubernetes Manifests on deployment graph screen
Easily view the Kubernetes manifests deployed using CD-as-a-Service from within the UI. Previously, understanding which manifests were deployed in a deployment required tracking down the manifest files in your source control repository. However, now you can conveniently access and review the manifests directly within the CD-as-a-Service UI. This feature simplifies the process of identifying potential issues with Kubernetes manifests that may not meet your expectations.
To view the Kubernetes resource manifests, simply click on the “View Deployment Config” link on the deployment graph page. Then, select the “Kubernetes Manifests” tab to access and review the manifests.
Log in and Sign up using your Google and GithHub account
You can now sign up and log in for CD-as-a-Service using your Google or GitHub credentials. With our latest update, it’s easier than ever to create an account or log in. Simply click on the “Login with Google” or “Login with GitHub” buttons, and you’re all set! No more manual data entry required.
For users who have previously created an account using a username and password, you can now use the social sign-on option to access your existing account.
Note: If you are using an external Identity Provider (e.g., Okta, Google Workspace), please ensure that you use your accounts configured with the external Identity Providers.
2023 June 01
New system-provided context variables are now available
Several new armory-provided context variables are now available for use in your web-hooks and automated canary analysis configuration.
{{ armory.namespace }} - this variable will inject the namespace to which a target is deploying.
{{ armory.accountName }} - this variable will inject the name of the account to which a target is deploying.
{{ armory.environmentName }} - this variable will inject the name of the target to which you are deploying.
{{ armory.applicationName }} - this variable will inject the name of the application that you are deploying.
These configuration variables can be useful when passing this information into a web-hook to simplify web-hook configuration for certain use-cases by reducing the need for custom context variables.
2023 April 07
Added ability to redeploy old version
It is now possible to easily redeploy any old version, by clicking the ‘redeploy this version’ button, and choosing which environments you want to redeploy to. This can be used for rolling back days or weeks after a version has been fully deployed to production. This option will not be available for older deployments, but is for all future deployments.
View deployment configuration
It is also now possible to view the configuration of a deployment in the pipeline for easier reference. This is useful for helping new users see how existing deployments are configured. This option will not be available for older deployments, but is for all future deployments. Watch demo
Updated login look and feel
The sign-in experience now has an updated look and feel.
2023 April 03
Can now pass url from Expose Service to Webhook
When defining a webhook, it can now pass the URL of any services exposed using the expose service step to the webhook. This can be used to run automated tests against the exposed service.
Here is an example that passes the exposed url for the service ‘potato-facts-internal’ into a github actions workflow:
- bodyTemplate:
inline: |-
{ "event_type": "checkLogs", "client_payload": {
"callbackUri": "{{armory.callbackUri}}/callback", "service":"{{ armory.preview.potato-facts-internal}}"
}
}
headers:
- key: Authorization
value: token {{secrets.github_token}}
- key: Content-Type
value: application/json
method: POST
name: Integration_Tests
retryCount: 3
uriTemplate: https://api.github.com/repos/mycompany/myrepo/dispatches
2023 March 29
Add Descriptions and context variables to deployments
Remove the burden of pre-existing knowledge when looking
at application deployments. With descriptions, you can
add context about the application within the deployment.
You can add things like application owners, link to
source control repository, link monitoring dashboards
and more. Adding descriptions to deployments can be done
simply by adding a description field in the
deployment manifest and providing it a string value.
description: |
This is a deployment for the sample application. Github link: https://github.com/armory-io/cdaas-examples
context:
foo: bar
Additionally, it is now possible to define context
variables in the deployment file. The context variables
are accessible from within webhooks and canary analysis.
It is still possible to pass context variables at
runtime using the --add-context flag in the
CLI.
Read Add New Context Variables at Deploy Time for more information.
2023 March 14
Added Ability to Expose an External Preview URL for any Deployed Kubernetes Service
We’ve added support for creating service previews.
Armory can now leverage its remote network agent to expose a preview URL for any Kubernetes service it deploys. CD-as-a-Service can generate a cryptographically secure URL for applications developers. This url can be shared with teammates and stakeholders who need to review the deployed functionality. This enables developers access to deployed services on-demand without a dependency on other teams to set up networking.
To enable a preview service for your deployment, add an expose service step to your canary or blue/green strategy:
- exposeServices: # step name
services: # list of services to expose. Service must be included in the manifests being deployed.
- potato-facts-internal
- potato-lies-internal
ttl: # Optional. Sets lifetime of the exposed service preview. After that period service preview automatically expires. Max lifetime cannot exceed 24 hours, Min is 1 minute, default is 5 minutes.
duration: 30
unit: MINUTES # SECONDS, MINUTES or HOURS
See Configure a Temporary Preview Link to a Deployed Service for more info.
2023 Feb 05
New Get Started Experience
Getting started with CD-as-a-Service is now easier than ever. The new user’s onboarding experience sent them into the configuration page, which was slightly confusing. Users are now taken to a dedicated wizard like setup experience. This allows them to easily deploy the sample application and get started with deploying their own application without having to learn a new YAML structure.
2023 Feb 04
Canary Deployments Can Now Use Istio Service Mesh
CD-as-a-Service now supports using the Istio service mesh, which allows you to implement precise control over the exact percentage of traffic received by the next version of your app. When you use a pod-ratio canary strategy, you can only approximately control the correct traffic split. When you use Istio, however, you can achieve fine-grained traffic control over your canary deployments.
To integrate Istio with CD-as-a-Service, add the traffic management block as a top-level field in your deployment config file and provide the Istio resource names.
Check out Configure Traffic Management With Istio for more information.
trafficManagement:
- targets: [staging]
istio:
- virtualService:
name: istio-sample-vs
destinationRule:
name: istio-sample-dr
2023 Jan 14
Can now deploy any Kubernetes Manifest
You can now deploy any Kubernetes manifest, including CRDs for Operators without needing a deployment object.
CD-as-a-Service has historically only supported deploying manifests alongside an object of Kind Deployment. Now, Armory can deploy any set of Kubernetes manifests, not just those with Deployment objects. This enables some new use cases, such as:
- Armory can deploy CRDs for operators such as Argo Rollouts or CrossPlane. This allows Armory to orchestrate cross-cluster deployments of software that is using an Operator within the cluster.
- This also allows deploying standalone workloads that are not deployment based, such as CronJobs or StatefulSets using CD-as-a-Service.
You do not need any extra configuration to start with deploying operators and other Kubernetes manifests. Simply specify the paths to your Kubernetes resource in the manifests section of your deploy yaml and deploy using the CLI or GitHub Action.
When deploying manifests that do not contain and
Deployment object, the ‘Strategy’ will be ignored. You
can still use beforeDeployment constraint
for manual approvals and other actions. When deploying
to an operator use web-hooks in an AfterDeployment
constraint to add operator-specific logic that waits for
the operator to finish processing the updated CRD.
Known issues
Objects of Kind ‘Custom Resource Definition’ must be deployed before objects of the kinds they create.
2023 Jan 04
Invoke webhooks without needing a callback
You can now use webhooks asynchronously during
deployment. Until now, using webhooks required a
callback for the deployment to continue or rollback,
which was not ideal for use cases like event streaming.
webhooks now has an optional boolean field
disableCallback. When you set this field to
true, CD-as-a-Service does not wait for the callback to
continue deployment.
The following is a sample configuration for defining an asynchronous webhook:
webhooks:
- name: Sample_Integration_tests
method: POST
disableCallback: true
uriTemplate: https://api.cloud.armory.io/sandbox/webhoo
headers:
- key: Content-Type
value: application/json
bodyTemplate:
inline: >-
{
"callbackUri": "{{armory.callbackUri}}/callback",
"success": true
}
retryCount: 3
strategies:
canary-20:
canary:
steps:
- setWeight:
weight: 20
- runWebhook:
name: Sample_Integration_tests
Feedback
Was this page helpful?
Thank you for letting us know!
Sorry to hear that. Please tell us how we can improve.
Last modified November 29, 2023: (6604991)