Welcome to the blogpost supporting the AWS re:Invent 2024 session “DEV335 – The modern CI/CD toolbox: Strategies for consistency and reliability”.
We aim to not only summerize but also enhance your session experience with this blog post.
Please do not hesitate to reach out and ask any questions that you might have in the comments or reach out to us directly on socials.
If you’re an old-school person, reach out to us by eMail.
Session walk-through and contents
CI/CD foundations
Continuous integration (CI) involves developers merging code changes frequently, ensuring that the cumulative code is tested regularly—preferably multiple times a day. Continuous delivery (CD), on the other hand, requires manual approval before deploying to production, while continuous deployment is entirely automated.
Unified CI/CD pipelines
Thorsten emphasized the importance of having a single, unified pipeline for all kinds of changes—whether they are application code updates, infrastructure modifications, or configuration changes. This helps maintain consistency, reduces risks, and simplifies compliance.
Code signing and attestation
According to Gunnar, ensuring the integrity of the code through signing and artifact attestation is paramount. This practice verifies that the code hasn’t been altered improperly, tracing each change back to a trusted source, which significantly reduces the risk of tampering and supply chain attacks.
GitOps: a new look at operations
Johannes took an in-depth look into how GitOps integrates Git with operations, streamlining deployment decision-making. GitOps supports a fast, automated transition into production environments without manual intervention, making it powerful for Kubernetes and other cloud-native projects. The main takeway is that with implementing GitOps, the decision to deploy a change to production is taken by the team members close to the context of the change instead of being taken by a “Change Advisory Board” or managers that are far away from the actual change.
Deployment strategies for minimizing risks
Several deployment strategies, including rolling deployments, blue-green deployments, and canary deployments, were outlined by Gunnar. Each strategy offers a different balance of speed and risk, with options to revert back to previous versions quickly if issues arise. You will need to choose the strategy the fits your business needs and your applications requirements.
Drift – Avoid it at any option
In this section, Johannes highlighted the challenges that come around with “Drift” in deployments – which is defined as any kind of manual changes that are done in your cloud deployment without going through Infrastructure as Code (IaC) and CI/CD. We gave the guidance to ensure that noone should get access to the target account to perform manual changes, instead, you should implement a “break-glass” pipeline that is focused on speed to recover form application downtime by rolling forward through CI/CD.
Ensuring consistency across pipelines
Torsten introduced an innovative approach to maintaining pipeline consistency using constructs. By centralizing the standard pipeline templates and allowing teams to extend them, organizations can adapt to specific needs without sacrificing consistency. This method also assists in managing migration between various CI/CD platforms effectively.
The role of security and compliance
Security and compliance are non-negotiable, integral parts of any CI/CD process. Integrating these practices from the beginning ensures that both security and compliance standards are maintained throughout the development lifecycle.
Feature flags and progressive delivery
Gunnar highlighted the importance of feature flags and progressive delivery in decoupling deployment from feature activation. With feature flags, changes can be made dynamically without redeployment, enhancing agility and reducing risk. This approach, used by companies like Netflix, enables controlled risk management and early detection of issues.
Avoiding vendor lock-in with projen-pipelines
Thorsten presented a possibility for CI/CD practicioners to adapt an open source project called projen-pipelines that empowers developers to switch between different CI/CD vendoers by allowing to define the pipelines in Typescript and implementing a renderer process that is able to generate pipeline code for Gitlab, Github, CodeCatalyst and bash.
Conclusions
The insights from this session highlighted the ever-evolving nature of CI/CD practices, where automation, innovation, and stringent security measures play crucial roles. As we continue to refine these practices, it’s clear that the right blend of technology and methodology can significantly impact the efficiency and reliability of software delivery processes.
Next steps
To dive deeper into these strategies, check out the resources and links provided below. Engage with the wider community to exchange ideas and best practices, and continue evolving your CI/CD processes to meet future challenges.
Thank you for attending this session and for taking the time to read the additional information provided here.
Please do not hesitate to reach out and ask any questions that you might have in the comments or reach out to us directly on socials.
If you’re an old-school person, reach out to us by eMail.
A few weeks ago AWS CodeCommit became a deprecated service on AWS. This means, customers cannot create new repositories anymore – refer to this announcement for all details: Blog for CodeCommit
There are obviously a lot of alternatives to CodeCommit (Github, Gitlab, …) but if you need a “self-hosted” Git repository in your own AWS account this can become a little bit harder to provision.
If you’re looking for a “self-hosted” Git server, a bunch of tools come up:
…and obviously also others or just a “git” server running on EC2
As I wanted to be able to deploy something that works “out of the box” I looked at how to provision one of these alternatives on my own AWS account.
Gitness
Gitness is an open source development platform packed with the power of code hosting and automated DevOps pipelines. It’s biggest mantainer is Harness. It includes “way more” than just Git – eg Gitspaces, Pipelines, etc.
Deployment of Gitness
If you want to deploy Gitness, the docs point you at running it locally using Docker, or by deploying it on EC2 or k8s.
My aim was to “only” make the “Git” component available and because of that I’ve chosen Amazon ECS with EFS as storage to provision Gitness.
Open Source Code for the deployment of Gitness
I’ve set up a project on Github where all of the code examples are available for you to look at:
In this post you will learn how to build a Custom BluePrints in Amazon CodeCatalyst. You will get to know how Custom BluePrints allow you to generate a consistent setup of your projects and CI/CD workflows and how you can leverage this to empower your teams to be compliant with rules and deployment best practices. AWS has announced this today at his annual user conference AWS re:invent 2023 in Las Vegas.
Custom BluePrints – what they do, why they are there and how you can use them
Custom BluePrints can be seen as “project templates” that you can build and offer to all of your users of a space. As a user of CodeCatalyst you should already be aware of the general concept of a blueprint: It’s a templated project that you can start your software project on.
Custom BluePrints take this concept to a new level: Now you can build BluePrints for your projects! And that’s not it: a project can be depended/generated by multiple BluePrints and a project generated from BluePrints can also become a BluePrint! yey! You do not start from zero and you are now also abled to add a BluePrint to an existing project.
Think about what this means for you and your organization: You can set up certain default workflows, permissions, dependencies, environments, etc. and apply that to all of your new projects by default, without the need to “touch” anything.
And that’s not “it” – there is more: CodeCatalyst also allows you to “update” projects that have been build from a Custom BluePrint!
Think about the scenerio where you ahve over 20 microservices that all follow the same CI/CD pattern, including governance rules and dependencies. They all have the same dependencies and pre-requisites (e.g. AWS account permissions, environment setups, etc.). Now one of the dependencies has a critical, security relevant defect and you urgently need to upgrade all of these projects…
CodeCatalyst Custom BluePrints enables you to do exactly that with just a few clicks and pull request approvals!
I hope you are curious to look at this new functionality in details now, keep reading!
The technology behind blue prints – the power of Projen and Code Generation
Custom Blue Prints are powered by Projen under the hood – to learn more about Projen, please look here. Similar to a projen.rc.ts you will need to create a blueprint.ts file in the src folder of your BluePrint project. There you can then define the rules and automations which will be applied when the BluePrint is used as a starting point for a new project. Currently the Custom BluePrint SDK allows you to define Wizard configurations, Workflows, Environments, Source Repositories, Pre-Configured Dev Environments, … Using Projen as an underying technology the team is able to re-generate the code for your project and create a pull request on your behalf for the source repository of your project i there is changes. And this is great!
Building your first BluePrint
Building your first BluePrint is easy!
Create your BluePrint project
It starts with creating a new Custom BluePrint project in the CodeCatalyst UI using the BluePrint builder. This one can be accessed from the Space “Settings” page. After going through the wizard, this will create a new project for you in CodeCatalyst. In this project, you can now either checkout the source repository into your local IDE or you can use the DevEnvironments to directly get you started to work on the project.
Building and Editing Custom BluePrints can be a HIGH RISK
As you are reading this and as the functionality has only just been announced, it might be early – but it is never too early to warn about this:
If you edit a Custom BluePrint and potentially introduce security problems – maybe even unsecure dependencies – you might expose everyone that uses your BluePrint to challenges.
Better set up additional protections for all of your BluePrint projects!
Edit the sources of your BluePrint Project
Now that you your project is set up, you can start building your own components and parts of your project.
Be cautious to edit package.json in your BluePrint project – you can, but it might break some of the integrations. The typescript project is set up for you to be able to preview and publish your BluePrint.
The main “sources” of your BluePrint and the definitions will be in the src/blueprint.ts file. Initially, the project comes with a simple wizard set up with only a few parameters. It copies only the contents of the static-assets directory when being executed.
I’ve not been able yet to try out a lot of the functionalities and possibilities of the SDK, but still I was able to create a custom BluePrint that can be used to deploy a Flutter Web application with a Serverless Backend.
What I found out is that it will be a huge effort to set up the BluePrint in combination with a Wizard. This is not a 4 hour task, we’re rather talking about a week to get started. Further details on this – see the “Testing” section. This might also explain why this functionality is part of the new Enterprise tier for Amazon CodeCatalyst.
Please read the available options of package.json, but to get you started: use npm run blueprint:synth or yarn blueprint:synth to generate the BluePrint locally.
This will also execute any local unit tests that you have build for your BluePrint.
Testing your Blue Print locally
Using npm run blueprint:synth or yarn blueprint:synth will generate the BluePrint bundle locally and execute unit tests. It will generate a version of your project created by the BluePrint in the folder synth/synth.[options-name]/proposed-bundle/. This will use the default options you provided.
It is also possible to simulate the wizard adding the --cache parameter.
You could also build Unit Tests or SnapShots tests and integrate them into this lifecycle step of the build procedure.
Publishing your BluePrint to the Space Catalog
Use npm run blueprint:preview or yarn blueprint:preview to upload a “preview” version of your BluePrint to your CodeCatalyst space. This will make the Custom BluePrint available but not make it available in the catalog yet, so users cannot use it.
It also automatically increases the version number for your BluePrint.
Testing your Blue Print through the UI
After publishing your BluePrint preview from your local environment, you will now see this preview version within your Space Settings. From there, you are able to create a project out of the Preview version of your BluePrint.
Here you will need to test all options of the wizard and in addition to that verify that the customizations that you added have been correctly generated after you went through the wizard.
I have made the experience that a whole testing cycle can take 3-5 minutes – so I really recommend you to look at local unit tests.
After you have finished your tests, you can add a specific version of your BluePrint to the BluePrint catalog. This is currenty only be possible through the UI in the Space Settings.
Creating (one or many) projects from your BluePrint
Now you are ready to start creating projects from your BluePrint!
Go to the normal “Create Project” screen – after using “Create from Blueprint” you will now have the option sect “Space Blueprints” which is where you will find your newly created BluePrint.
This should now generate your project from your BluePrint and the structure should be as you wanted it to be. 🙂
You can also add additional BluePrints to an existing project – this allows you to incorporate multiple BluePrints in a single project, a combination of multiple “default” project settings.
Please be aware that this will remove manually added or created resources that are part of the BluePrint that you are adding – it will overwrite manual changes that “interfere” with the BluePrints code.
Upgrading your BluePrint
Upgrading your works similar to creating it – upload a new “Preview” version, add the new version to the catalog.
Upgrading your projects to a new BluePrint version
You can currently update the used Blue Print vesion for a project by going to the project settings, to the Blue Prints section there and then by loading up one BluePrint. Choosing to upgrade to a different or newer version will generate the proposed changes and make them visible to you before you apply them.
What’s next for Custom BluePrints?
Oh wow, this is one of the new features that I am most excited about for CodeCatalyst! There is so much potential! I have to explore further the possibility to have multiple BluePrints attached to a project, the possibility to remove a BluePrint from a project, and all of the other things that I didn’t touch yet.
Here’s stuff that I would love to get for Custom BluePrints:
auto-apply updates to ALL projects that are from the same BluePrint automatically
share Custom BluePrints with other Spaces
a Custom BluePrints market place where developers (like me) can put “their” BluePrints in and organizations can “buy” a BluePrint from
I also believe that the team needs to work a bit more on the developer experience when building Custom BluePrints, e.g. by pre-suggesting automated integrated tests (integration or snapshot tests). Publishing a new version to the catalog should also visualize the changes that are going to be added to other projects before you actually publish the new version.
I am a bit disappointed that the “free tier” does not give you the possibility to try out this functionality by being able to add one or two Custom Blue Prints to your space, but maybe this is something that will be possible as soon as the Blueprint SDK is stable.
What do you think of Custom BluePrints? What are your main wishes? Please reach out to me and let me know!
Both Christian and I have been writing about our “Football Match Center” project – and as part of this project we obviously also needed a CI/CD (Continuous Integration and Continuous Deployment) pipeline. Our aim was to be able to integrate changes that we do regularly and see commits to the main branch being directly and automatically deployed to our environments.
I will first try to define some pre-requisites and then talk about learnings and experiences.
What is a mono-repo
A mono-repo is an abbreviation of a “mono repository” which I understand as being a single repository, where different microservices or components are stored and saved in the same git repository. This can be various different services, infrastructure or user interface components or backend services.
A mono-repo has special requirements when building the CI/CD pipeline.
Expectations for our CI/CD pipeline
For our CI/CD pipeline we wanted to be able push changes to production quickly and be able to iterate fast. We wanted to achieve 100% automation for everything required for our project. As we have been writing, we completely develop this project using Amazon CodeCatalyst and thus the pipeline also should be build using the Workflows in CodeCatalyst.
Going forward we want to ensure that the pipeline also includes all CI/CD best practices as well as security scans and automated integration or end to end tests.
How to structure your pipelines
In this article we will purely focus on the CI/CD pipeline for your “main” or “trunk” branch – the production branch that will be used to deploy your software or product to the production environment.
We will not consider pipelines that should be executed on feature branches or on pull request creation.
The “one-pipeline-to-rule-them-all” approach
In this approach all services are deployed within the same pipeline. This means that there is only a single pipeline for the “main” branch. All services that are independed rom each other can deployed in parallel, services that have a dependency need to be deployed one after another. Dependencies or information from one to another service can be pushed through the pipeline using environment variables.
This can lead to longer deployment/execution timelines but ensures that “one commit” to this “main” branch is always deployed completely after a commit. If tests are included in the pipeline, they will need to cover all aspects of the application.
The “context-specific” or “component-specific” approach
Different components or contextes get a different pipeline – which means that e.g. the backend-services are deployed in one pipeline and the frontend-services in a different pipeline.
In this approach, you automate the deployments for components and need to ensure that, if there are dependencies between the components, the pipeline verifies the dependencies. If one component requires information from another one you need to pass these dependencies using other options.
This can lead to faster iteration cycles for specific components but increases the complexity of the pipeline dependencies. You can also do not directly see if a specific commit has been deployed for all components or not.
The “one-pipeline-for-each-service” approach
This is the most decoupled option for building a CI/CD pipeline. Each service (lambda function, backend, microservice) gets its own pipeline. For each service, you can implement service specific steps as part of the pipeline.
One of the main requirement for this is that the services are fully decoupled, otherwise managing dependencies can get very difficult. However, this allows a very fast iteration and development cycle for each microservice as the pipeline execution for each service is usually very fast.
The pipeline needs to verify the dependencies for each service as it executes the deployment.
Football Match Center – our experiences with building our CI/CD pipeline in Amazon CodeCatalyst
For our project we decided to start with a “mono-repo” – in our case today, we have a CDK application (written in Typescript) that describes the required infrastructure and includes Lambda functions (where required) and a user interface which is written in Flutter.
From a deployment perspective, the CDK application needs to be deployed on AWS and the Flutter application then needs to be deployed on a S3 bucket to serve as a Single Page Application (SPA) behind Cloudfront. Obviously this deployment/upload has the pre-requisite of the S3 bucket to be already available.
How we started
We started, very classic, with the “one-pipeline-to-rule-them-all” approach. We had one single pipeline that was used to deploy all services that are part of the infrastructure.
This pipeline started with “cdk synth” using the “CDK deploy” action in CodeCatalyst and then had other steps that depended on the first one – to executing the “flutter build” and later the “UI deploy” (using the S3 deploy action).
In this first version, the CDK deploy step had variables/output with the name of the S3 bucket and the CloudFront distribution ID passing it it to the next step where the output of “flutter build” was then uploaded and the CloudFront distribution invalidation request was triggered.
In this approach a commit to the “main” branch always triggered the same pipeline and this pipeline deployed the complete application.
We also used only natively available CodeCatalyst actions for deployment – “cdk deploy” and “build”. For the Flutter action we used a Github Action for flutter.
Experiences and pipeline adjustments
With this approach we had the problem that the Flutter build step took ~8 minutes and blocked a new iteration of changes in the CDK application or the lambda function. Thus, this slowed down our development cycle.
In addition to that we found out that there was no possibility to influence the CDK version with the CDK deploy action – but we wanted to be able to use the version defined in our Projen project – to be able to deploy to development environments from our local with the same version as from the CI/CD pipeline.
Both of these findings and experiences brought us to implement some changes to the pipeline:
We separated the UI build from the CDK build
We moved away from using “cdk deploy” and replaced it with a “build” step – to be able to trigger “projen” as part of the pipeline
So now we have two pipelines:
CDK deployment
Triggered on changes to the “cdk-app/*” folder
Executing CDK synth, build and deploy steps – but not using the “cdk deploy” action but a normal build step instead
We adjusted the CDK app to include Cloudformation exports that exports the S3 bucket name and the Cloudfront distribution ID
Ui deployment
Triggered on changes to the “ui/*” folder
Reads the values for the S3 bucket and the CloudFront distribution ID from the CloudFormation exports using the AWS cli
Executing the Flutter build steps and the S3 deploy action
These changes reduced in faster iterations for the development cycle of the CDK app and allowed decoupling the backend from the UI part. We were also able to fix the CDK version to the version we have selected in Projen.
In our project we have chosen the “context-specific” approach for the pipeline.
My recommendations for building CI/CD pipelines for a mono-repo
Our CI/CD pipeline is not perfect yet and we’re yet to add some important things to our pipeline.
From the experiences we have made I am still not convinced that our “context-spefic” approach is the right path.
As of writing this post in early April 2023 I’m inclined to move towards a model where we combine the “context specific” and the “one-pipeline-to-rule-them-all” approach: context-specific for “lower”, non production environments and then a single pipeline that does the promotion to our production environment.
Today we do not yet have a production environment, so we did not answer that question yet 🙂
How do you solve this challenge around building CI/CD pipelines for mono-repos?
At re:Invent 2022 AWS announced Amazon CodeCatalyst and as you might have read on my blog or seen on my YouTube Channel I have been playing around with the service a lot. A few days ago, Brian asked me a few interesting questions, one of them being:
What’s the diff between CodeCatalyst and AppComposer?
Lately we had a Community Builders session with the Amazon CodeCatalyst team and similar questions came up in regards to comparing CodeCatalyst with other, already existing services.
And to be honest, the amount of AWS services that are related to building, managing or deploying software projects on AWS has grown a lot in the last years and it gets difficult to keep an overview of how these services play together and which tool has which functionality.
In this post we are aiming to compare and place CodeCatalyst in relation to other (new or already existing) AWS Services. We are also going to look at missing functionalities that are currently available in other services but not in CodeCatalyst.
Please be aware that these are all our personal opinions and based on our own understanding – some of it being assumptions.
This post was Co-Authored with AWS Community Hero Brian Tarbox – Thanks for your support!
AWS Services that we are going to compare CodeCatalyst with:
Amplify was released at re:Invent 2018 and has since then been improved gradually.
Amplify is a complete solution that lets frontend web and mobile developers easily build, ship, and host full-stack applications on AWS, with the flexibility to leverage the breadth of AWS services as use cases evolve.
With that AWS positions Amplify as a service that is able to reduce the heavy lifting on web or mobile developers that want to get started on AWS. AWS has extended Amplify into being a service that offers nearly all building blocks required as part of your SDLC process. It does not offer source code repositories, but CI/CD capabilities. You are able to configure the CI/CD pipeline and also provide your own build images. With the release of Amplify Studio in 2021 AWS extended the capabilities to include a “No-Code/Low-Code” capability that allows rapid-prototyping for web and mobile applications. The target audience for Amplify are Front-End and Mobile developers with no to minimal experience on AWS.
Application Composer
This is a new AWS service announced at re:Invent 2022 mainly focused on “rapid prototyping” helping you to quickly “paint” serverless applications – build our your architecture out with visualizations, Application Composer will create the required “starting code” (Cloudformation, but also Lambda code) in the background. As output you get a project in code that you can then commit to a Git repository or deploy out to AWS. Application composer enables Serverless developers to quickly prototype serverless applications and convert them into code that can then be used as a starting point for your project. Application composer does not provide Source Code management or CI/CD capabilities.
The service, which reached GA on March 8th of 2023, points at developers starting new serverless projects that quickly want to get both an architecture diagram as well as a starting point for further developments.
App Runner
This is a AWS service announced in 2021 and it can be used to build, deploy and run web applications based on containerized workloads. It allows you to stay focused on your application with the service taking responsibility to provision and host your application. It also takes care of creating a container from your source code. You can connect App Runner either to your source code management system or to a container registry.
Beanstalk
This is one of the “ancient” AWS services – it was announced in 2011 and has since then been around. In the community I have more than once heard that “Beanstalk is dead” and not being actively developed anymore, but still – it works and can be used to provision your web applications. At the same time, you will still be able to access the infrastructure that is required to host your service. The “message” is similar to App Runner – it helps developers to focus on writing business code and ignore the deployment strategy. Beanstalk supports Java, .NET, PHP, Node.js, Python, Ruby, Go and Docker web applications. In order to use Beanstalk, you will need to upload a source bundle – it is not possible to connect beanstalk automatically to a Git repository, but you can update the source bundle automatically using APIs.
We treat these services in one group as they belong together from a strategic point of view. They have been around for a few years and the teams that built these are now involved in CodeCatalyst. CodeCatalyst partly uses them “under the hood”. CodeCommit is a managed git hosting, CodeBuild is a managed “build” system, CodeStar is a “project management” tool. CodePipeline allows combining multiple CodeBuild steps to form a pipeline. CDK Pipelines integrate with CodePipeline today. With CodeArtifact users are able to store artifacts and software packages.
All of these services are tied to a specific AWS Account and live within the AWS Console. This has forced organizations and AWS customers to create “toolchain accounts” that centrally host these services. These tools might be considered as building blocks rather than a full solution.
CodeCatalyst
As we are comparing the other services with CodeCatalyst, we also need to define what CodeCatalyst is: a new AWS service announced at re:Invent 2022 that will cover the full lifecycle of product development on AWS, starting from the source up to the deployment part. It is an “All-in-one” solution to help you build software on AWS efficiently. You can manage your planning and issue tracking in it as well as your source code and your CI/CD workflows. I have a few introduction videos recorded available on YouTube. CodeCatalyst lives “off” the AWS Console and this means that you do not need to be logged in to use it – and it can access multiple AWS accounts by an integrated authorization process.
Proton
This is a AWS service announced in 2020 – and AWS describes Proton as a service to allow central teams to build and provide central infrastructure components that can easily be shared with users while at the same time maintaining the integrity of the deployed infrastructure. With that, the tool is focused on infrastructure provisioning (=deployment) pipelines. Proton allows the central “platform team” to provide templates to be used by application teams – with only minor changes or configurations to it.
Which problem(s) does CodeCatalyst address?
CodeCatalyst addresses the need of developers or of development teams that need to cover all parts of the product life cycle or parts of it with a tool natively built on AWS. It can be used for issue management and planning as well as source code management. It has natively built CI/CD capabilities with workflows for Continuous Integration and Deployment. CodeCatalyst offers an opinionated solution for addressing software development best practices on AWS. It also allows online-editing of source code with the Dev Environments and supports the management with reports on resources and workflows managed as part of CodeCatalyst.With Blue Prints it allows developers to quickly start a new project and reduces the time to get a new project started. It can be seen as an opinionated approach to development.
So, how does CodeCatalyst relate to the other services?
Out of the six services we looked at, a few can at first glance not compete or be compared with CodeCatalyst as they target a different audience or address different problems as CodeCatalyst:
Proton – does not help with building or deploying code, it is targeted towards “composing” an application from various pieces. As such, it might be part of a solution but not the whole solution
Application Composer – while this service can be used to do a rapid-prototyping for serverless architectures, it does not allow source code management or deployment of the built architecture. I hope that we will see Application Composer as a new option for starting off a new project in CodeCatalyst going forward
Beanstalk – is not a “developer focused” tool as it comes with pre-build environments and CI/CD pipelines and expects you to manage the source code externally
Based on this, the services we want to look at in more details are:
While Amplify allows to build CI/CD pipelines and manage deployments for both Front-End and Back-End components of an application, the pipelines and deployments are limited to the services supported by Amplify and the capabilities of the automatically generated CI/CD pipeline. There is not much flexibility to adjust the pipelines. In addition to that, Amplify does not allow you to store your source code or to manage your software project. It has no build-in issue management or tracking system.
With Amplify Studio and the corresponding tutorials you get the possibility to quickly get started on specific use cases. This is not as flexible as the CodeCatalyst Blue Prints but gets you started pretty quickly. Amplify Studio is awesome as a “low-code”, getting you started tool – it allows you to quickly build full-stack applications through a User Interface and for that use case it is definitely better than CodeCatalyst. At the Berlin Summit in 2022 I attended a Live Demo of Rene Brandle and was amazed by the functionalities.
Amplify Studio lives “outside” the AWS Console in the same way as CodeCatalyst and it also requires an AWS account to be connected for deployments. Each Amplify project can be connected to one AWS account. This is more flexible in CodeCatalyst.
Still, Amplify misses a lot of things that are required for an end-to-end “DevOps” tool to manage all processes and requirements of an agile software development project.
Comparing CodeCatalyst to the Code* services (CodePipeline / CodeCommit / CodeBuild / CodeStar / CodeArtifact) feels a bit like comparing a Tesla Model 3 with Karl Benz’ Patent-Motorwagen 🙂
The Code* services feel complex to use, although they provide similar functionality than CodeCatalyst if you combine them together. They are “building blocks” that you as a developer can use to build “your own version” of an integrated Developer Toolchain.
In addition to that they live in a specific AWS account, as mentioned above, which makes the handling of access complicated and requires you to have an IAM user that is allowed to access them.
The user interface and possible integrations are minimal and feel “developer unfriendly”. CodeCommit has the CodeGuru Reviewer integration which is currently not available in CodeCatalyst.
CodeBuild (and with that CodePipeline) is very slow in bringing up new, fresh “build instances” – so starting a new pipeline execution can take minutes which is bad for developer productivity. This is something that CodeCatalyst is addressing with the “lambda” execution environment.
Summary, takeaways and our wishes
As per the messaging, blog posts and announcements from AWS around CodeCatalyst, we believe that the service today aims to offer an opinionated tool for development teams that want to practice “You build it, you run it” – in line with the DevOps mentality. It also means that AWS shows the courage to not only give builders a tool at hand but also “influences” what they build with Blue Prints that include best practices. The vision for CodeCatalyst however could be even more than that: a tool, powered by KI capabilities that empowers builders to efficiently develop and build high quality software by reducing the manual work and efforts through automation.
However, CodeCatalyst is not yet there and it’s going to take some time and effort from the team to reach this.
Wishes for Developer Tooling in General
This post has shown that AWS offers a lot of different possibilities to handle software projects on AWS. We made clear that all of the available tools serve a different purpose and target a different audience. While Amplify focusses on Web or Mobile developer and Application Composer targets Serverless developers, Code Catalyst takes a more generalist approach.
Overall, the “Developer Tools” landscape on AWS needs:
More and better guidance on WHEN to use WHICH service
Better “HOW TOS” instead of hard-to-read documentation or specification
Wishes for CodeCatalyst
Compiling a wish-list for CodeCatalyst can be a big effort as there are still a lot of features that we would like to see. We’ll touch on a few ones here:
General
Single Sign On without Builder ID – Okta/Ping/etc.
Other regions support
Allow “Open Source” projects
Issues / Tracking
Epics
Roadmap / Timeline
Integration with Workflows & Automation
Source
Import projects from Git providers
Automations on Pull Request
CodeGuru
Security Review
Best Practice Review
Support of pre-commit hooks when editing online
Verifications, linting, etc. automated
Workflows
More triggers (e.g. by PR, by schedule, by API)
Conditional Steps
Manual approvals
App Store / Play Store deploy actions
Projen Action
Better integration with AWS services
Import existing CodePipelines
Pipeline as Code – CDKPipelines like option to create workflows from code
What wishes do YOU have for Code Catalyst? What is your “most hated” or “most loved” feature today?
A few weeks ago, on december 1st 2022, Werner Vogels announced Amazon CodeCatalyst. I’ve previously shared my initial thoughts and findings in a blog post. In this post, I’m going to share a few more findings and insights into using Amazon CodeCatalyst and will also see if any of my wishes from the wishlist for CI/CD on AWS have been resolved with CodeCatalyst.
What I have been playing around with…
CodeCatalyst login page
One of my personal projects that I am working on together with a few friends is pegasus-galaxy.net and the CI/CD pipeline that I had built with CDK Pipelines (that I also presented at re:Invent 2022) was the first one to try to move over. In context, we’re talking about a Flutter application for Web running behind CloudFront, deployed using CDK.
I decided to try CodeCatalyst out and go “all in” – and that means moving the code from Bitbucket into CodeCatalyst as well as setting up the other users in CodeCatalyst and moving the workflows (=CI/CD pipelines) over to CodeCatalyst.
CodeCatalyst Menu
In this article I am going to go through each of the sections in CodeCatalyst and will share my experiences, thoughts and findings.
Where I have ideas on how to improve the day-to-day work with the tool, will try to share that.
Before going into details, lets start with the most important thing:
Amazon CodeCatalyst works very well and reliable and the current version of the service is a great foundation for moving all of your CI/CD and development practices to AWS.
The CodeCatalyst team has been very supportive on re:Post, so if you have a question, feel free to ask it there!
CodeCatalyst Overview – Spaces and Projects
Spaces are the “Top-Level” option to organize your CodeCatalyst account. You will need to associate an AWS Account for billing used AWS resources. Each AWS (billing) account can be associated only with one CodeCatalyst Space.
CodeCatalyst Spaces Billing page
While this seems like a limitation as you will need to create a different billing account for a 2nd space, I can right now not see an impact for my day to day work. For anything that I run on the same AWS account, I would assume that using a project within the same space should be good.
You can manage Projects, Members and AWS Account connections on the space page. In the “extensions”, CodeCatalyst currently allows a connection only to the JIRA Cloud. I would expect that additional 3rd party extensions will be supported in the GA version of CodeCatalyst.
Projects Overview and options
A project is a “unit of work” in your product or software that you are building. Within projects, you can manage issues, manage your code repositories, execute workflows (CI/CD) and review report results.
Projects are associated to a Space – and you can create as much projects in a Space as you want. You can add team members to a project, that are not able to access all projects in the space. Unfortunately I have not yet found an option to “hide” projects from Team members that are added on the Space itself.
Managing issues / tickets
CodeCatalyst currently provides two options to manage your issues or tasks: 1) Link to JIRA Cloud Project 2) Internal issue management
If you use the option to link to a JIRA cloud project, the “issues” link is replaced by a link to your JIRA Cloud project.
Internal issue management
The internal issue management system currently offers everything that is required for a simple Kanban workflow. You can create issues, add them to a backlog or a Kanban board, assign them to project members and track their current status. I personally think that the current functionalities are good enough for small teams and simple projects – I’m actually already working with it in a small project and will add additional feedback as soon as I gain more experience.
Code
Within the “Source” part of a project, you can manage source repositories or connections to source repositories in Github. I expect that other providers will be added going forward (e.g. Gitlab, CodeCommit, Bitbucket, …). You can also manage pull requests and approvals – I was only able to test this using internal source repositories, not using a linked repository.
The last option – the Dev Environments – is the most exciting functionality – it gives you the possibility to host development environments (similar to Gitpod) on AWS using Cloud9 but also, and this is really cool, using Visual Studio or JetBrains IDEs. When using that option, the IDE on your local PC is only the “presentation layer”, the source code is stored and run on an AWS instance and the IDE uses remote connectivity to talk to the Dev Environment in the background.
CI/CD
CodeCatalyst currently uses the same approach as Github Actions to manage your workflows or CI/CD pipelines – you are able to manage your Workflows using YAML files. The syntax is simple and understandable. There is a minimal set of Actions available as part of the preview. You are also able to use existing Github Actions as part of your workflow.
Workflow overview in CodeCatalyst
The workflow functionality is very powerful. In my tests I have not yet been able to test all parts of the capabilities. Workflows can be defined for certain directories, for certain triggers or branches. Test reports will be exposed in the “reports” functionality.
CodeCatalyst offers a graphical overview for workflows and alows to edit them in the UI, too. This functionaly works pretty well and helps to quickly get you started building your first workflow in CodeCatalyst.
I’ll need to test the workflows more to be able to give additional insights into how good or bad they are currently running. My simple pipeline that builds a Flutter Application, deploys my Infrastructure as Code using CDK and then publishes the new version of the Flutter app runs without problems.
One of my main concerns so far is the execution time, however the team has been working on a possibility to use Lambda as an execution environment. This option however does not yet support the execution of Github actions and also has some other limitations.
The other features that are part of the “CI/CD” – Environments, Compute and Secrets – I did not have time to play around with this. If you have any experiences with it, please add your thoughts in a comment to this article!
Reports
The reports today only suport test reports. I have not used the functionality enough to assess this, but I am sure that the CodeCatalyst team is going to add additional reporting options going forward.
Things I like most about CodeCatalyst (Preview) after 6 weeks of usage
Just a short list of things that I already like: – Integration of Github Actions as workflow actions – Managing workflows using UI & code
Things I miss in CodeCatalyst (Preview) after 6 weeks of usage
– macOS builds (e.g. for Flutter iOS apps) are still not possible – granular permissions for workflow and Pull Request triggers – and….
Let’s talk about Open Source Projects
Right now there is no option to share a project or a repository that is hosted within CodeCatalyst as an Open Source project. This is really a limitation if you want to use CodeCatalyst for Open Source project – or if I would like to share a CodeCatalyst repository with example workflows. I hope this functionality will be added soon.
Wrap up and next steps for me with CodeCatalyst
I need to admit – writing this post took longer than expected 🙂 I wanted to publish it before christmas and now it seems to be a bit “late” already as I am sure that a lot of you have made your own experiences with CodeCatalyst today – please SHARE your findings with me – links of Blogs that you have written or other content you have created, I am eager to consume it!
My next steps with CodeCatalyst
I am working on migrating my project pegasus-galaxy.net completely to CodeCatalyst and collaborate with my team on it there. With that, I will be able to proof CodeCatalyst in a “real world” application that it is “multi-platform” application – using Flutter for Web, Android and iOS – and a Serverless AWS based backend. If you’re interested to join this project, please do not hesitate to reach out – skills that we need right now: AppSync, DynamoDB and development/software engineering (Flutter, Typescript, Java, or Node?)
In this post you are going to get to know the new service that AWS announced at re:Invent 2022 in Las Vegas. With this new service AWS brings the Code* tools (CodeStar, CodeBuild, CodePipelines, etc.) into one user interface and opens up the usage to new audiences.
Amazon CodeCatalyst is a service that helps you to manage your project code in a central place and allows integrating it with existing CI/CD tools. It also simplifies the cross account functionalities of CI/CD best practices. With the market place functionality it opens up the tool for further expansion through third party contributors.
Functionality highlights
Organizations and projects
CodeCatalyst allows the set up of an organization and projects within that organization. This allows a structured set up of your projects and allows you to segregate access. What I have not been able to verify is if existing organizations of AWS Organizations are automatically imported and available in the service. This would be beneficial for larger organizations that want to get started with CI/CD on AWS.
Integration with your “builder ID”
Amazon CodeCatalyst is integrated with AWS your builder id – and that means that you can have a unique, personal account. This account is not tied or attached to an existing AWS account. The integration with the AWS accounts it done through cross account permissions that are created automatically for you. This concept has various benefits:
You (as a developer) can have access to the required CI/CD structure and code management without the requirement to have an IAM user or access to the AWS console to the specific AWS account that you are aiming to deploy to
You (as a developer) can have access to different “organizations” and “projects” within the service – which will make it easier for 3rd party teams working on AWS projects (e.g. consultancy engagements)
You can allow the CodeCatalyst workflows to only be able to deploy into certain accounts and the list of accounts that you can connect to from a specific project or organization can be modified on demand
Unified user interface and workflows
The new user interface of CodeCatalyst allows to look at the complete lifecycle of your product – form development to deployment – within the same window. You can easily set up a project, connect or set up a repository and then create a CI/CD pipeline (or workflow) for it. You will also be able to visualize the workflow of your CI/CD pipeline during creation or editing.
Integration of Github Actions
With the integration of existing Github actions and the possibility to re-use already available automation steps within your workflow AWS opens the door to re-use and migrate a lot of already existing functionality. This is going to be very beneficial and will help to drive the adoption of the service. The availability of “native” actions as part of CodeCatalyst is still limited and I assume with the Marketplace new actions will be made available quickly and the list of available actions will grow rapidly.
Project Templates – CI/CD pipelines
I believe that this is the most important functionality of the service. Allowing to quickly set up new applications, workflows or projects on the service empowers developers to get started efficiently. I’m eager to see additional templates going forward. As you can include both infrastructure and application code, but also the required workflow in a template (=that’s your deployment pipeline), I hope that with this functionality we will be able to empower developers to re-use better CI/CD pipelines that enforce a DevSecOps mindset and include all of the “best practices”. I would love to see all of the reference implementations of the “DPRA” (Deployment Pipeline Reference Implementation) implemented as templates in this service.
A good, automated CI/CD pipeline helps your developers to focus on creating business value – the more you can “re-use” or drive through standards and templates, there more efficient your teams will be.
Additional wishes
As I have not explored all areas of CodeCatalyst yet, some of my “wishes” might already be implemented and I did not yet discover them – here’s a few things that I’d love to see but haven’t found yet. Please reach out to me if this is functionality that is available somewhere and I’ve missed to find it 😊
Re-applying project templates
I would love to be able to re-apply a project template to an existing project, especially for the workflows. This allows two things: 1) if you’ve changed the workflow and it doesn’t work anymore, you can quickly go back to the working version. 2) if the template changes, you can re-apply the changes to a project without the need to access every project manually.
In combination, some times a project changes or evolves and you might want to move it from a “backend” project-template to a “full-stack” project. This can today only be achieve manually but not in an automated fashion.
Better “mobile app” support
As you’ve maybe read, I’m working on a “Flutter” application – and because of that I would really love to see a possibility in CodeCatalyst that better supports the “cross platform” app functionality. Today, the service mainly focuses on provisioning AWS infrastructure. As you build a complex project that also needs to publish a mobile application, it would be very bene be able to use the service to also publish the application itself into the different stores automatically. Of course there are other, 3rd party systems that already allow that, but if you want to use CI/CD natively on AWS this is currently not possible. I know I’ve mentioned that before, but as I have not seen the possibility to perform an iOS build on CodeCatalyst, I wanted to highlight it again.
Additional 3rd party integrations / workflows
One of the assets of the service is definitely the market place functionality that will quickly allow to integrate new 3rd party services. What I would like to see here is the support of additional repository stores besides Github (e.g. Bitbucket, Gitlab, and the corresponding “datacenter” versions), but also the possibility of a native integration of other tools that are required as part of the CI/CD pipeline – things like Codecov, SonarQube, Checkmarx, Snyk, Aquasec, etc. This might be possible through custom actions, but I am not yet clear on how fast these will be available.
Infrastructure as Code support for provisioning and setting up your CodeCatalyst environment
I’m not clear about the possibility to set up your CodeCatalyst environment through Cloudformation/CLI calls or through CDK/Terraform and I am unsure if that would be something that is required for this service. What would definitely be good to have is the possibility to set up integrations to your existing accounts and projects in an automated form – the CLI commands make that possible, but that’s not the same as directly defining it “as code”.
Native branch support for projects & workflows
CodeCatalyst allows to refer to different branches, but it would be cool to get a possibility to natively support “ephemeral” environments as part of your CI/CD process. There are two use cases that I have in mind:
Integration tests as part of the CI/CD process (workflow) that require the infrastructure to be available and provisioned
Environments to replicate/test defects or new functionality
For both of these use cases, the CI/CD tool should be able to deploy an environment from a branch – and then also automatically de-provision it based on rules. Today this is something that you would need to manually replicate within your workflows and infrastructure as code.
Overall summary and outlook
The service is overall is a great addition (or maybe a replacement?) of the existing Code* tools on AWS and it streamlines a lot of things that were previously not working perfectly on AWS. For a new service it’s a solid launch with a lot of benefits, especially for small companies or open source projects that do not have the possibility to use existing third party tools or really just want to focus on generating business value. I do not think that CodeCatalyst will be able to replace existing Jenkins installations or services for bigger enterprises right now, as there are a few things that are not yet possible.
What do you think of CodeCatalyst? Please share your thoughts and feedback with me (either on the comments, on LinkedIn or by mail.
As I’ve been sharing before, I am very fortunate this year and will be giving a DevChat at the biggest AWS conference of the world – at re:Invent 2022 in Las Vegas.
AWS offers different tools for all parts of your CI/CD lifecyle. In this post I am going to cover the set of Code* tools that are available on AWS today – and will share my thoughts about what these tools are missing.
As part of the preparation for the talk and as part of both my private project (code-name: MPAGA) and my main job @ FICO I have been researching and learning a lot about CI/CD (Continuous Integration and Continuous Deployment) – and for the private projects especially around CI/CD that natively runs on AWS. I’ve found out that not everything that these tools offer today is perfect and wanted to share some ideas on what could be improved. Where possible or applicable, I will also propose workarounds or alternatives.
We will look at a few of the tools in the order of the “product lifecycle”: 1. Code 2. Build/Test 3. Deploy 4. Release
Tools that are part of the “Code” phase
For the purpose of this post we are going to focus on tools that are natively offered by AWS as already mentioned and part of your CI/CD pipeline.
AWS CodeStar – Integration of projects
AWS CodeStar enables you to quickly develop, build, and deploy applications on AWS and provides a unified interface for your project. It provides you different templates that you can choose from to quickly start your project.
It allows you to manage your team, with permissions and integrates with your existing JIRA for issue management. It also integrates with your IDE (or with Cloud9). You can also integrate with an existing Github repository.
AWS CodeCommit – hosted Git
AWS CodeCommit is a managed service for Git (just like Bitbucket, Github, Gitlab, …. It provides a hosted “git” environment that is encrypted at rest and can be accessed using usual Git clients.
AWS CodeGuru
Amazon CodeGuru is a developer tool that provides intelligent recommendations to improve code quality and identify an application’s most expensive lines of code. Integrate CodeGuru into your existing software development workflow to automate code reviews during application development and continuously monitor application’s performance in production and provide recommendations and visual clues on how to improve code quality, application performance, and reduce overall cost.
Tools that are part of the “Build” or “Test” phase
AWS CodePipeline – Tool to manage your CI/CD pipeline
AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application and infrastructure updates.
AWS CodeBuild – Build tool based on containers
AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces ready-to-deploy software packages.
AWS CodeArtifact – artifact storage
AWS CodeArtifact allows you to store artifacts using popular package managers and build tools like Maven, Gradle, npm, Yarn, Twine, pip, and NuGet.
Tools that are part of the “deploy” phase
AWS CodeDeploy
AWS CodeDeploy is a fully managed deployment service that automates software deployments to various compute services, such as Amazon Elastic Compute Cloud (EC2), Amazon Elastic Container Service (ECS), AWS Lambda, and your on-premises servers.
AWS FIS
AWS Fault Injection Simulator (FIS) is a fully managed service for running fault injection experiments to improve an application’s performance, observability, and resiliency.
Tools that are part of the “Release” phase
AWS AppConfig (part of Systems Manager)
AWS AppConfig makes it easy for customers to quickly and safely configure, validate, and deploy feature flags and application configuration.
Wishlist
I’ve been able to gain some experience with the tools while working on a few projects, including cdk-codepipeline-flutter and here is a list of things that I believe could be improved. My main focus here is on CodePipeline, as it serves as the glue between all of the other tools.
Native branch support for CodePipelines
Working with Jenkins and the MultiBranch plugin makes it easy to allow developers to quickly test and deploy code that they are working on using the CI/CD pipeline. Unfortunately, CodePipeline today does not allow automated branch discovery, so if you want to enable the automated execution of a pipeline for a branch, you will need to manually configure webhooks and then create a new pipeline (or delete an existing pipeline) when branches are created (or deleted). This is not easy to implement and it would be great if CodePipeline should natively allow creating a pipeline automatically for all branches of a linked Git repository.
Additional Templates and Best Practices
When setting up a CI/CD pipeline on AWS CodePipeline, this would be easier to use if additional best practices and templates would be available as part of the tool itself. AWS is starting to promote a new Open Source project called “Deployment Pipeline Reference Architecture“. this is a step in the right direction, but it needs to be expanded by other flavours of a deployment pipeline. Also the code examples need to be improved, made up to date and needs to include all languages supported by AWS CDK. This is critical to allow an efficient adoption of the different tools.
Native integration of 3rd party tools
AWS CodePipeline should natively support integrations to other 3rd party tools that should be part of your CI/CD pipeline – e.g. security scans like Aquasec and Checkmarx.
Remove dependency for a specific AWS account and support Cross-Account deployments natively
As indicated in this AWS Blog post, the best practice for setting up a CI/CD pipeline and for managing your deployments is to use multiple, different accounts to manage your deployments. CI/CD should not be bound to an account level and this includes the management of your accounts that are able to access and configure the CI/CD tools. Maybe a good option here would be the integration with the AWS Identity service. That might allow decoupling the CI/CD toolchain from the AWS account.
Up to date CodeBuild images
Docker Images provided by the CodeBuild team should be updated regularly and should support all “modern” toolkits. The open source project has some activity, but an issue for supporting newer Android versions is now open for some time…
Publishing options to the different mobile stores (AppStore, Play Store, Windows Store, etc….) should be possible
I’ve been looking at developing a mobile app using Flutter, but what I have not yet been able to achieve is pushing the created and build applications to the different app stores. Today, AWS does not support this natively. You CAN integrate this with 3rd party tools like CodeMagic, but natively there is no option on AWS to publish your application.
Wrap up
This concludes the wish list that I have today for the existing AWS CI/CD tools.
Did I miss anything that you believe should be added?
Use the comments to give feedback or reach out to me on LinkedIn or by E-Mail!
