Go and Forge your AWS environment in CloudFormation

Forge is a project which I’d had on the back burner for some time now, and in early 2018, I decided to embark upon developing it. The idea behind it is to make it easier to deploy CloudFormation stacks from Continuous Delivery platforms by decreasing the boilerplate logic required in all of a team’s pipelines.

Forge a tool which can deploy AWS CloudFormation within Continuous Delivery platforms (such as BuildKite and CircleCI) reliably, with the event reporting and status checking that is required from actions in a deployment pipeline. The problem which Forge solves, is that native AWS tooling such as awscli is not designed for automated workflows on AWS; it’s designed as an easy to use interface for a developer to access the APIs for AWS services, which it does a great job of. As an answer to continuous delivery workflows for CloudFormation, AWS provide CodePipeline. For straightforward use cases, CodePipeline can get a team off the ground, but for teams who are looking to leverage their existing CI/CD platforms (perhaps for native integration with their organisation’s preferred version control system), or build more complex deployment workflows, this is where Forge comes in.

I wrote Forge as a project in Golang in order to provide a portable and self-contained tool which developers could just pick up and use. Fewer dependencies on a dev’s machine makes the dev experience much easier to provide at scale. Not only is Golang great as it provides a compiled binary as an output, but the development experience is fantastic using it. Testing is built into the language, and mocking the AWS functions is very achievable by overriding interfaces in the test functions; once the mocking approach had been developed, I was able to perform test-driven development by writing unit tests with inputs and expected outputs, then developing against that until the tests passed (TDD FTW!)

Forge has a strong feature set which lends itself to automated delivery pipelines, notably including synchronous deployment of stacks with active event output, an exit status based on stack deployment state, and automatic determination of create or update actions.

Forge is un-opinionated, with the view to manage a single CloudFormation stack, but help provide a smooth and controlled deployment process for it. If you’re looking to develop integrations between CloudFormation stacks, Forge’s philosophy is that you should use native CloudFormation constructs such as cross-stack resource references to achieve them; this results in a reduced dependency on Forge for the management of your environment because it’s still all native CloudFormation! If you were so inclined, you could switch to awscli at a later stage with minimal effort.

If you need to deploy CloudFormation on a frequent basis, give Forge a go to help you do it. If you find it useful, reach out to me on Twitter @nathan_dines, or if you think it can be improved, issues and pull requests are welcomed on GitHub.