{"id":7660,"date":"2025-02-26T09:00:00","date_gmt":"2025-02-26T08:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7660"},"modified":"2025-03-26T10:47:08","modified_gmt":"2025-03-26T09:47:08","slug":"lets-talk-about-pipelines-in-the-post-aws-codecommit-era","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/lets-talk-about-pipelines-in-the-post-aws-codecommit-era\/","title":{"rendered":"Let’s talk about pipelines in the post-AWS CodeCommit Era"},"content":{"rendered":"\n
The DevOps philosophy and the evolution of software development led to the automation of application build and deployment operations. Thanks to application and infrastructure pipelines, developers no longer carry USB drives to the system administrators’ office to deploy the new software release!<\/p>\n\n\n\n
For those of us who develop cloud-native applications on AWS every day, the first step to kick off a project is creating a Git repository.. Since July 9, 2015<\/a>, the most natural step has always been to click on the CodeCommit section of the AWS console and select \u201cCreate Repository.\u201d<\/p>\n\n\n\n Just over 9 years later (on July 31, 2024), we learned that this habit would have to change following Jeff Barr\u2019s announcement on X.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n The news surprised everyone: essentially, new AWS accounts created after July 31, 2024, will no longer be able to access the service, however, accounts in AWS organizations where repositories were already present will still be able to access the service normally.<\/p>\n\n\n\n The service is not in the process of being decommissioned, as was hypothesized in the days following the announcement; security updates, bug fixes, and maintenance are guaranteed, but no new features will be developed.<\/p>\n\n\n\n Although AWS CodeCommit has never provided advanced options for collaborative coding, its strength has always been its integration with the various automation and deployment tools offered by AWS (like CodePipeline, CodeDeploy, and Amplify).<\/p>\n\n\n\n There\u2019s already been a lot of discussion about the reasons that may have led AWS to make this decision. Our goal, instead, is to explore the different available alternatives, highlighting the pros and cons based on various scenarios<\/p>\n\n\n\n A key aspect is its integration with IAM, which allows you to manage Git permissions using already-registered users: defining the allowed Git operations (pull, push, merge, etc.) directly within IAM policies, making it quick and easy to manage.<\/p>\n\n\n\n You can also create notification and approval workflows directly integrated with the AWS Cloud (like Amazon SNS, Amazon EventBridge). On the other hand, switching to a different Git provider might require creating integrations that are no longer directly configurable on AWS.<\/p>\n\n\n\n Moreover, the service’s cost is incredibly low, enabling anyone to get started without navigating a maze of features offered by countless different usage plans.<\/p>\n\n\n\n Having governance over AWS ecosystem services in one centralized point, federated with the corporate Identity Provider, including management of development tools, provides a holistic view, simplifies processes, and facilitates the implementation of a Landing Zone. The integration of CodeCommit with IAM is a key piece in putting together the puzzle of permissions and access management.<\/p>\n\n\n\n Despite all the positive aspects described, it was undeniable that AWS CodeCommit had some pretty evident limitations.<\/p>\n\n\n\n The first was the limited number of integrations with tools outside of AWS. Nowadays, it’s crucial for a code repository tool to offer various integrations beyond just managing branches and resolving conflicts. Almost all the main vendors now provide solutions directly integrated with third-party products, offering users a seamless 360\u00b0 experience on their platforms.<\/p>\n\n\n\n The second major limitation was the poor implementation of features for collaborative development and code reviews. While the possibility of performing ‘pull & merge requests’ was available, its implementation was quite basic (not to mention the user experience). Today, collaborative development tools offer much more advanced user interfaces, alongside a vast range of complex and advanced features for code review and comparison.<\/p>\n\n\n\n AWS probably never intended CodeCommit to directly compete with specialized collaborative development tools. Instead, it aimed to provide an integrated option in the context of centralized governance of accounts and resources. And that’s precisely why the sudden announcement caught us off guard.<\/p>\n\n\n\n “As we\u2019ve already mentioned, AWS CodeCommit is no longer available for newcomers to AWS, but the service isn\u2019t being discontinued: there\u2019s no need to panic or come up with emergency strategies, but it\u2019s still a good idea to start evaluating the available alternatives.<\/p>\n\n\n\n First, we need to figure out which of the many options best suits our needs and resources.<\/p>\n\n\n\n AWS directly recommends some vendors, including the well-known GitHub, GitLab, and BitBucket. The main driver behind this suggestion is, once again, the integration between these platforms and AWS services. The deciding factor might boil down to one simple question:<\/p>\n\n\n\n \u2018What\u2019s the actual use case for my repository?\u2019<\/p>\n\n\n\n In the next section, we\u2019ll try to match the most common answers to this question with the various products available on the market.<\/p>\n\n\n\n There are very few services (both AWS and non-AWS) that the three platforms mentioned above don\u2019t integrate with. In fact, all three can be configured directly as a source step for AWS CodePipeline through the creation of a CodeStar connection. For both GitHub and GitLab, you can use either the SaaS or self-hosted version.<\/p>\n\n\n\n If we decide to use one of these solutions, the question naturally arises: \u2018Do I really need AWS CodePipeline?\u2019<\/p>\n\n\n\n If we previously used AWS CodeCommit because it was convenient and right there in the same AWS CodePipeline console, now that we\u2019ll have to use an external service, it might not be worth sticking with AWS pipelines.<\/p>\n\n\n\n Both GitHub, GitLab, and BitBucket offer integrated pipeline services. Compared to AWS, these services are designed to leverage a wider range of technologies and the most common third-party products. Switching to these types of pipelines could simplify all those intermediate steps that often needed to be orchestrated using complex AWS CodeBuild workflows.<\/p>\n\n\n\n At the same time, AWS has shifted its development efforts toward tools aimed at improving the developer experience and offering better integrations\u2014for example, with GitLab. It\u2019s now possible to configure runners using AWS CodeBuild as the compute platform, allowing for more granular permissions control compared to the past when interacting with cloud resources. Who hasn\u2019t encountered EC2 runners with full AdministratorAccess permissions?<\/p>\n\n\n\n Even GitHub Actions are now integrated, and integration with BuildKite has just been announced.<\/p>\n\n\n\n “There\u2019s also the ‘do-it-yourself’ alternative: even a simple Git repository accessible via SSH can trigger hooks and perform actions. However, managing your own repository, and investing time to ensure high availability, security, and maintenance, doesn\u2019t really offer advantages compared to managed services that already guarantee these aspects and allow you to focus on real business needs. That said, this option shouldn\u2019t be completely ruled out for very specific requirements or unique cases.<\/p>\n\n\n\n<\/figure><\/div>\n\n\n
Why AWS CodeCommit: its strengths<\/h2>\n\n\n\n
Weaknesses<\/h2>\n\n\n\n
Alternative codebases: GitHub, Gitlab, Bitbucket <\/h2>\n\n\n\n
The \u201chomemade\u201d<\/h4>\n\n\n\n
Conclusion<\/h2>\n\n\n\n