Coaxing AWS Amplify to play well with Azure DevOps

Coaxing AWS Amplify to play well with Azure DevOps

Using a simple Azure DevOps Build Pipeline to feed Amplify for Continuous Integration and Deployment

The project

The client I'm working with operates only in AWS - however - they manage all of their code in Azure DevOps. In building out a rapid prototyping site, I needed a mechanism that was light and fast. It seemed that AWS Amplify fit the bill - at least at first. I have years of experience building machine learning workloads, data stores, micro-services and streaming services in AWS, but Amplify was relatively new to me. I started with integrating against a private GitHub repo (instead of an Azure DevOps repo) as a crutch since it was so easy to configure with Amplify. There was no out-of-the-box ADO integration, so I initially took the path of lesser resistance. I figured that if the web app matured from a proof-of-concept to a fully fledged product, I could just move it over to the company's Azure Dev Ops instance - update the endpoint and PAT - and that, as they say, would be that.

To PAT or not to PAT

When it came time to make the move over to a company managed repo, I spent some time looking into how to mirror my Azure DevOps repo into AWS CodeCommit, and let Amplify take things from there. Azure DevOps has a task for handling Git mirroring, so it was a matter of wiring things up and letting a simple build pipeline do the heavy lifting. AWS CodeCommit has an odd wrinkle to it that it doesn't support generation of a PAT - or personal access token. After some research (mainly by reading open-ended support questions in various forums) I found that using the Git credentials for a service account is a proper substitute. The construction is akin to

$(AccessID:AccessKey)

where the value is stuffed into a variable within the Azure DevOps build task context. The rest of the task setup is pretty garden-variety boilerplate work.

Service Account Notes

I tried to cheat/short-cut the process by simply using my own AWS Admin (Git) credentials in the ADO Pipeline task, and it failed quite spectacularly. It turned out that the constructor for passing in the PAT would lop off the first part of my my Access ID (my email address) at the "@" symbol. That caused a few minutes of head-scratching, but fortunately the Git Mirror Task in ADO returned a pretty straight-forward error message. So - I did what I should have done to begin with and created an "Amplify" service account with the correct (minimal) permissions and everything worked as expected. But let this be a warning that if you use an account that uses an email address pattern for the AccessID, the script will break.

An understated CI/CD process

If you're accustomed to setting up a highly instrument process per-branch in ADO (or any other build orchestrator) then Git mirroring is going to feel a bit light. But don't let it fool you. It's a bit counter-intuitive to set up a single build process (that only points to the repo level - not the branch) to perform the sync for any and all of your branches. But if you think about it - with a disciplined code promotion procedure you're only acting on one branch at a time. So even if the mirroring process reflexively updates both - only the branch with an active delta will be updated. So on the receiving end the CodeCommit repo will "see" an update only for branches where a change exists. In this case, with each environment (I just have an "int" and "main" branch) CodeCommit picks up the changes and Amplify performs the build and deployment for each branch respectively.

Worth a Thousand Words

I created this time-compressed video to illustrate a quick walkthrough of how the process operates. It includes a sample push to int and then merge to main - with the respective sync to the CodeCommit and follow-on Amplify deployments per environment.

Additional Work

There are still some wrinkles to iron out - mainly on the Azure DevOps side. It's a fairly naive` process - in that it "expects" to work every time - and for now I consider that a relatively low risk. However there should be some error/recovery processes instrumented - even if it's just a notification on an error condition.

Summary

Really this sidebar is about two nits: 1. the PAT that's not a PAT, and 2. a wrinkle in the Access ID name pattern that could cause an error. Otherwise it's a relatively straight-forward and surprisingly light-weight process. The video is a fairly complete picture of how the mechanism operates, so feel free to watch and pause at the important highlights to see the working model. I really like it, and getting two occasionally antagonistic cloud spheres to play well together is always fun.