Jack Jackson dc73161dd9 First pass

Next steps:
* Update other repos to use this
* Blog about it :P

2022-10-25 16:31:49 -07:00

6.2 KiB

Raw Blame History

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 stage¹, 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	Variable meaning	Example value
BRANCH	The branch of the Infrastructure Repo on which to make a commit	`main`
GIT_REPO	The (https://) address of the Infrastructure Repo	`https://github.com/myusername/coolrepo`
IMAGE_TAG	The Image Tag to insert into a tracking file	`a6b6e8`
DESTINATION_FILE	The file in Infrastructure Repo that should be updated to contain `IMAGE_TAG`	`deployed_tags/prod_image_tag`
AUTHOR_EMAIL	The email that should be associated with the automated commit	`myname@gmail.com`
AUTHOR_NAME	The name that should be associated with the automated commit	`Adam Nonymous`
COMMIT_MESSAGE	Commit message. Expands environment variables (note that any of these variables should have `PLUGIN_` prepended if you are referencing them)	`[Auto] Automated commit to write $PLUGIN_IMAGE_TAG to $PLUGIN_DESTINATION_FILE`
ACCESS_TOKEN	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". ↩︎

6.2 KiB Raw Blame History