6.0 KiB
TL;DR
This Drone plugin makes (and pushes) an automated commit to a Git repo. Use this to create a step in a Drone pipeline that updates an IaC repo ("watched" by a CD system) to reflect a newly-available image of Application Code.
Information
Motivation
The GitOps development style encourages:
- Defining the infrastructural elements of an application in Source-controllable form (using an IaC tool such as AWS CDK, K8s manifest files/Helm Charts, etc.)
- Using Continuous Deployment systems (such as AWS CodeDeploy or ArgoCD) to ensure that the deployed state of the application matches the intended state, as defined in checked-in version-controlled specification.
Updates to infrastructural definition are naturally propagated out to deployed environments via the operation of the CD systems. However, updates to the application code should also result in deployments (once that application code has passed all appropriate tests), but this is not natively supported by CD systems - since Infrastructure definitions tend to define the specific App Code version that should be deployed to each stage1, making a deployment of a new App Code version requires an update to the Infrastructure definition as well. This plugin automates that process.
Operation
This plugin assumes that the mapping of "which Image tag should be deployed to which deployment stage" is managed with simple files - for each stage, there is a single file which contains only the tag that should be deployed to that stage. Examples of this setup can be found in the sample repos for App Code & Infra Code.
Variables
| Variable name | Required? | Variable meaning | Example value (default value for optional variables) |
|---|---|---|---|
| BRANCH | No | The branch of the Infrastructure Repo on which to make a commit | main |
| AUTHOR_EMAIL | No | The email that should be associated with the automated commit | auto-update-bot@example.com |
| AUTHOR_NAME | No | The name that should be associated with the automated commit | Auto Update Bot |
| COMMIT_MESSAGE | No | Commit message. Expands environment variables (note that any of these variables should have PLUGIN_ prepended if you are referencing them) |
[Auto] Update $DESTINATION_FILE to $IMAGE_TAG |
| GIT_REPO | Yes | The (https://) address of the Infrastructure Repo | https://github.com/myusername/coolrepo |
| IMAGE_TAG | Yes | The Image Tag to insert into a tracking file | a6b6e8 |
| DESTINATION_FILE | Yes | The file in Infrastructure Repo that should be updated to contain IMAGE_TAG |
deployed_tags/prod_image_tag |
| ACCESS_TOKEN | Yes | Personal Access Token providing access to the Git Repo |
FAQs
Couldn't you just do this by declaring the deployed tag as a Parameter of the Argo deployment?
Honestly - that's probably a better approach. I'm still learning about CI/CD after my previous life as an Amazon SDE, and figuring out capabilities and best practices is taking a while (I've earmarked the great answers to this SO question to read, but haven't gotten to it yet). Nonetheless, this was a neat opportunity to learn how to make a Drone plugin! I'd prefer to "get my hands dirty" implementing both approaches before I make a decision on which I prefer.
-
As I discuss here, Amazon's own internal CI/CD system didn't use this pattern, instead declaring the App Code element that should be deployed to a given Compute element (Lambda/ECS/etc.), and letting the Pipeline system control determine "the latest App Code revision that has passed all preceding tests". Part of my intention in writing that blog post and in creating this plugin was to explore the default model of OSS CD systems - "The deployed-version of App Code should be determined by the contents of a Git Repo rather than by the state of a Pipeline" - and to understand its pros and cons vs. "the Amazonian model". ↩︎