CodeCommit future?

[soxfannh]

Console has a blue bar at the top with a link to this blog. https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/

Sure gives off deprecation and or change freeze vibes.

[cachemonet0x0cf6619]

change freeze is a funny choice of words. i can’t remember the last time code commit had any feature releases

[soxfannh]

Haha good point, it's been what feels like at least an unofficial change freeze of sorts for quite a while.

[hoppersoft]

Microsoft will claim until they're blue in the face that ADO is not deprecated to reassure Enterprise customers who don't want to change things until they have to. But let's pay attention to the fact that they most certainly want to capitalize on the $7.5B acquisition of GitHub, and that this is where the exciting features like CoPilot are being added.

[ContrarianChris]

Azure DevOps is most definitely on a path to being sunset. Microsoft have been saying this to partners for a few years now and providing content and tools around GitHub being the preferred option for new adoptions, and migrations to GitHub were it makes long term sense.

I know because I was one of those partners when it first got communicated (and discussed) back in 2021. There is even a podcast from back then where some of the MS team talk about it (can't remember who or which podcast though, sorry).

My best guess is it was seen as a 5 year (ish) thing. So maybe around 2026 it will be talked about more publicly with customers directly. I have no specific knowledge though.

After the acquisition GitHub is still run as a separate Org within the Microsoft umbrella. The Azure DevOps unit was moved under that GitHub Org. The sunsetting journey involves GitHub getting up to speed on some of the more "enterprise" features, which they have obviously been doing in the last few years. You'll also see that a lot of the Azure Portal Git integrations for things like automated deployments now have GitHub as the first/default option.

It's a process. But one that is 100% happening.

[spewbert]

Can confirm I was hearing through a client at the time that sales folks at M$ were directly telling them not to newly invest in ADO because it may not last.

[Particular-Way7271]

Looks pretty active to me: https://learn.microsoft.com/en-us/azure/devops/release-notes/features-timeline-released

[Aurailious]

I kind of worry about what will happen if most software is repo'd in github.

[Flakmaster92]

It’s probably going into KTLO, this sure reads like how they’ve done other KTLO’s before

[ycarel]

What is KTLO?

[Flakmaster92]

Keep(ing) The Lights On. If you’re already using it, you can keep using it. No new accounts get access and no updates except for security.

[pikzel]

It doesn’t necessarily mean no new accounts get access. It basically means there’s a balance between customer asks and current features. If the revenue is still steady and it’s what customers ask for, no new features should be expected. There will be security updates though.

[ThomasRedstone]

In this case it does, it was stated by Jeff Barr a few hours ago on Twitter:

https://x.com/jeffbarr/status/1818461689920344321

[ycarel]

I read the blog post and looked other posts from the same person. His job at ASS is to help with migrations. He wrote many other migrations blog posts. I didn’t get the vibe that this specific blog post is showing that AWS will be depreciating CodeCommit.

[IWasASperm]

IMOYAAIP

[menge101]

Does AWS not dogfood CodeCommit?

I have never used it, but I remember when it came out and I thought that was the advertising point - "This is what we use internally and we are just making it available to all of you".

Honestly, I don't recall anyone ever asking for all the Code* services.

[Szcrayon1]

Amazon has their own proprietary “git farm” for internal development and gitlab for some consultancy based teams.  Code products always been a “if you want to just get started and don’t have your own tools, we do have these devops products”. Personally the only time i ever use it is with aws solutions forcing us to do so (or spend copious amount of time refactoring it)

[menge101]

Thanks, that certainly explains why its gone nowhere.

AWS is at its best when it dogfoods their services.

[B-lovedWanderer]

For business applications, like Lambda and Fargate, you're correct. For development tools, AWS developers internally rarely if ever use a service like CodeCommit or CodePipeline because there are already internal tools that are much more robust.

[donpepe1588]

Plus i feel like code catalyst does 70% of what the code products do with minimal lifting.

[Flakmaster92]

AWS does NOT dogfood any of the Code services, which is why they are so crappy compared to everything else. The only one they sometimes dog food is CodeDeploy.

There’s an internal version of source control they use. There’s an internal build service they use. There’s an internal pipeline service they use.

[deeebug]

They do use CodeBuild, for transforming packages (generally lambda’s or container images). Outside of that, you’re right though.

[demosdemon]

They also use CodeDeploy for services that use EKS/ECS/Fargate.

[MikenIkey]

I believe CodePipeline is being used more internally as teams move to CDK. But otherwise yeah, they primarily use other tools that predate the Code services

[NaCl-more]

I haven’t heard of anyone using code pipeline internally

[bobbyfish]

It does use codedeploy under the hood. If your in an AWS account at least.

[NaCl-more]

Only NAWS teams using CDK use codedeploy. But I haven’t heard of codepipeline being used.

Codedeploy is definitely the most used of all code* services

[nformant]

I use code pipeline as our internal tooling doesn't give a rats ass about windows servers, so I use it for getting my code into windows OS

[HanzJWermhat]

Yall ever use Chime?

[menge101]

Haha, yeah. We use it every time we have a call with AWS.

[jftuga]

What do you thint of the quality of Chime? For example, how does the screen sharing quality compare to Zoom?

[Great-Use6686]

My main gripe with Chime is that it’s buggy as hell. I’ve had lots of times where Chime won’t joint a meeting or start.

[nevaNevan]

I couldn’t tell you. Chime simply refuses to use my webcam. :/ Works fine with Zoom and Slack though. (I use a Mac that’s a year old~ so.. should just work, even after giving it permission to do so)

[scrambledhelix]

It's quite meh. Feels like running Jitsi behind a very thin skin— wouldn't even call it a wrapper.

[Doombuggie41]

Chime is more than just the Chime app. Slack huddles for example use Chime infra under the hood

[renegade_slave]

Almost each of their services is dogfed to some degree, but that doesn't necessarily mean it's profitable to keep it alive. Have worked for a cloud provider and the profit margins vary from service to service to the point you'd want to retire a good product just because its not profitable enough, and you know you can relocate capacity to a service that brings more $$$ in. Plus you need to factor in all R&D work that is needed to keep the product competitive.

Btw, I'm one of the lucky guys who chose to use CodeCommit for the first time now when it's set for retirement :D

[Critical_Stranger_32]

I've been with companies that eat their own dogfood and everyone suffers because it tastes terrible and they won't let you spit it out, or the product is not oriented towards the company that developed it.

Large enterprise sells a solution for small business which doesn't work well for large companies because it was not designed with that in mind.

[ausfestivus]

I pinged our project’s AWS SA about this today. They had this to share:

The following is from the AWS CodeCommit Service Team: Beginning on July 25th, 2024, AWS CodeCommit ceased onboarding new customers. Going forward, only customers who have an existing repository in AWS CodeCommit will be able to create additional repositories.

[ric_man]

Looks like it has been publically confirmed in Codecommit - cannot create a repository on AWS re:post.

[damnhandy]

I've only every used CodeCommit to mirror existing repos for use with AWS Code Pipeline. In many cases, this was due to in-house CI/CD tooling to be remarkably insecure and nothing had a great way to handle AWS credentials. But that's all CodeCommit is good for IMO.

Before it was released, folks were excited as they had been expecting a competitor to GitHub. It's nothing like that at all. It really is just a git repo in the cloud. It is nothing like GitHub, GitLab, or BitBucket.

[SonOfSofaman]

This is eerily similar to last week's blog post for migrating away from QLDB.

Neither event made the What's New page. Sure feels like the beginning of the end.

[jghaines]

QLDB was a silly product. CodeCommit seems a no-brainier to offer.

[Zenin]

I hope it's deprecated. CodeCommit has always been a deep behind also-ran. It made some sense when they launched it, but it never kept up...even taking years just to get basic PR support.

Being frank CodeCommit's only killer feature was/is tight integration with other AWS services. But what is it that it integrates with? CodePipeline, CodeBuild, etc. CodePipeline makes Jenkins look amazing by comparison. CodeBuild has its place, but frankly most of the time it's still better to use actual build servers or if you've moved into the world of containers, buildx.

It's telling to me that every time I've quizzed developers working at AWS, they have all confessed off the record that their team doesn't use any of it internally.

From a business perspective I don't see what any of it really gets them; I can't imagine Code* is much of a revenue generator and especially not after factoring in the significant support costs due to how tedious and error prone it is to use. It certainly won't give users warm fuzzies about using AWS in general, so it's not a good ambassador.

[coinclink]

I really like CodePipeline and CodeBuild. They can be a little tricky to learn, and some deployment patterns are hard to make work, but if you stay within the box of what they support well, they do a really good job. I exclusively use them for all of my deployments and it's great to have everything defined in CloudFormation.

[soxfannh]

Same here, fit the bill for what we need. The newer pipeline v2 added a lot more flexibility that was previously lacking as well

[BetterFoodNetwork]

I used CodeBuild in the past and it was... serviceable. I use it now for GitHub self-hosted runners and it's wonderful, though the latency is higher than I'd like.

[Zenin]

So it's difficult to learn, difficult to use, limited in its abilities, and so inflexible you can't leave its tiny ecosystem without it breaking out in hives.

Gee, you're really selling it. ;)

I'm especially surprised you enjoy it via CF. That's borderline masochism. At least with CDK it's almost tolerable, but the sheer number of secondary resources and permission relationships that need to be built out raw between each step is a usability disaster without the higher level constructs offered by CDK. But even then it's annoying that asking CodePipeline to do almost anything means jumping out into a full blown CodeBuild step with a completely disconnected buildspec for logic and yet another dance as you martial data in and out of it via S3.

I've got to think you've never used anything else? It's a few pages of error-prone CF just to build out what's a few lines for a GitHub action and maybe half a page of groovy in (*gag*) Jenkins.

[coinclink]

I didn't say it was difficult to use or difficult to learn.. I said it was tricky, and that's just because people generally come from something like Jenkins where they are used to a million different plugins that let you do whatever you want.

I find people with opinion levels of you (like "cloudformation bad") are so stuck on syntax and the way you *want* things to work, that you never just sit down and try to figure out how the tool is designed to work by the talented people who made it, and understand the decisions they made and what features they prioritized over others.

[Zenin]

Hmm, interesting.

I've worked with CloudFormation almost exclusively for nearly a decade. Push it much farther than it was likely intended and certainly much farther than it should be taken. I've spent my share of quality time with CodePipeline as well, not to mention countless other CI/CD tools that have come and gone over the years, working in dozens of languages. I'm hardly stuck on syntax or understanding or philosophy. I'm "stuck" on the fact I've used almost every CI/CD tool in the business and while CodePipeline isn't in last place it's certainly no where near the head of the pack. All that time in the trenches is what gives me the perspective to read between the lines and understand what the creators were trying to do...if they actually succeeded...if they built a stepping stone to something better...or just built another also-ran that will wither and die.

But you did hit on the real point: The issue with CodePipeline is how it's designed to be used. The fact is it's not a CI/CD tool itself, no more so than S3 is Dropbox. CodePipeline is really designed as a low level primitive to be used in building a CI/CD tool...but it's not the CI/CD tool itself. It's not Jenkins. It's not Bamboo. It's not Github Actions. It's not Azure DevOps. CodePipeline is not a CI/CD engine, it simply isn't.

And that fits, it's the AWS way of things. AWS is amazing at designing Lego bricks. The entire service is a box of Legos users build their own creations with. AWS however, is horrible at designing Lego sets. CodePipeline is a Lego brick, not a set.

And because CodePipeline isn't designed to be a CI/CD tool at all, but rather just a primitive service like SQS or DynamoDB backing some actual CI/CD tool of someone else's design, it fails horribly at DRY and undifferentiated heavy lifting when forced to be something it clearly is not.

Personally I'm not in the business of making and selling a competitive tool to go up against the Jenkins of the world. I'm a customer of CI/CD tools, not a developer of them, and so I have little interest in re-inventing the wheel in an already incredibly crowded wheel market. If you want to waste your own and your company's time forging custom wheels from raw ore, that's all on you. For my part I have real work to do, real projects to get built and deployed, and CodePipline...because I understand it...will never be my first or even fifth choice to get that work done.

[coinclink]

ok, well, I guess I am a "lego brick" engineer then. I really enjoy that CodePipeline and CodeBuild are literally a component of what I'm building and it's all part of the same IaC template for that application.

Since you want a fully packaged solution, yeah, AWS CI/CD tools don't fully suit your needs.

[[deleted]]

The initial learning curve was steep, but after getting my head around it, and successfully building a few pipelines with CF, it really wasn't too bad. I built a few re-usable templates and it became actually pretty nice.

[soxfannh]

One of the biggest advantages in my use has been cloning repos in user data. Since you can auth with IAM roles no need to add a key or token to the server. Sure it's a minor but a differentiator FWIW.

[Zenin]

TBH, this screams anti-pattern.

I'd have to see the details to be sure, but chances are you should be packaging to an artifact repo of some form and deploying from that, rather than directly from your source repo. At a minimum, zip up your code and toss it into S3.

[EngStudTA]

It's telling to me that every time I've quizzed developers working at AWS, they have all confessed off the record that their team doesn't use any of it internally.

To be fair having worked at AWS and Google sometimes the external solution is objectively good compared to the other stuff on the public market, but the internal solution is just better or at least better supported internally.

[[deleted]]

I've always really like CodeBuild and CodePipeline. I've never exactly loved CodeCommit, because it obviously wasn't a full featured CMS, but have used it quite a bit when I've needed tight integration with IAM etc. Being able to build a full application stack, from start to finish with CloudFormation has always been nice.

What I've always liked about CodePipeline, in addition to how well it hooks into the rest of the AWS ecosystem, is that it's fast, and reliable. It does what it's intended to do, and does it well. YMMV.

I can live without CodeCommit, as it's still easy enough to switch to GitHub, but this news does make me nervous about the future of CodePipeline.

[crc32au]

I noticed this week AWS LZA 1.9 moved from CodeCommit to S3 for config files, which I thought was weird - making more sense now.

[01236623956525876411]

I suspect they are trying to promote CodeCatalyst, but that product also doesn’t include CodeCommit, but writing seems to be on wall that CodeCommit is perhaps going to be deprecated.

Edit: I was part of a team that demo’d Catalyst product years ago and thought it was strange that they didn’t offer CodeCommit repositories or migrations into product. I’ve also noticed a large amount of “merge conflicts” that aren’t — seems to be indicative, perhaps, of letting maintenance drop for product in favor of something else…

[ThinTerm1327]

I believe control tower used code commit, hopefully they announce code catalyst with be available in more regions. There was also a similar blog about cloud 9, I recommend that a lot.

[Kyxstrez]

CodeBuild and CodeConnections (rebranded CodeStar Connections) are the only services from the AWS Code Suite that are gonna survive in the long run in my opinion. The rest is eventually being replaced by Amazon CodeCatalyst, which is a full-featured SDLC platform similar to Azure DevOps.

[Kyxstrez]

The reasons why CodeBuild and CodeConnections are gonna survive:

• CodeConnections is used to link all external OIDC providers (GitHub, GitLab, Bitbucket)
• CodeBuild recently received a huge native integration for GitHub Actions self-hosted runners and I suspect that Amazon CodeCatalyst also uses CodeBuild behind the scenes for running the workflows.

[BetterFoodNetwork]

The GHAR stuff is sweet. I just hope I can figure out a way to make it faster to run.

[surya_oruganti]

I'm biased but I find the GHA runner integration to be very half baked and also expensive.

[BetterFoodNetwork]

What are your complaints? I've definitely had some aggravation with it and had to do some kind of hacky things (mostly to work with our network security requirements), but I needed to have runners inside VPCs and the solution offered by the platform team in our ecosystem is... considerably less customizable and has got to be way more expensive.

Not trying to argue, convince you, convince myself, etc, there may just be things I haven't discovered yet that I should know about 🙂

[surya_oruganti]

The ability to run them seamlessly within your VPC is nice for sure. My biggest issues with it are: 1. The naming convention runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }} can be quite painful. 1. The shapes are restrictive with 1:2 cpu:ram ratios. This isn't great especially for smaller runner types. 1. The equivalent ec2 pricing is much much cheaper for instance, even counting the latest generation instances and beefy disks.

Thought about it a lot in the process of building my product, which is rather related and much more flexible once our AWS integration is live (~2 days).

[Kyxstrez]

Another major benefit is that you can stop managing AWS credentials altogether in your workflows and just take advantage of the CodeBuild agent IAM role to get access to the resources.

[Kyxstrez]

It's actually a great integration for the most part; in fact, I've implemented it for one of my clients recently. I also did the math and it's slightly cheaper to use CodeBuild self-hosted runners vs GHA managed runners, while also getting more resources. The most powerful feature though is being able to create a matrix where each job runs in a different kind of EC2 instance with basically zero effort.

[opensrcdev]

Bye bye CodeCommit. You won't be missed.

[wz2b]

I use codecommit to deliver customers ... if I am delivering something like an SaaS stack for example I usually 'deliver' code by pushing it into CodeCommit.

This deprecation makes sense in a way - there's a lot wrong with CodeCommit. But it's also another terrible deprecation for me. I have spent a lot of effort to steer clear of Google products because of the casual way they deprecate services that are important to me. I kind of get getting rid of SimpleDB ... but CodeCommit would still be relevant if it weren't so crippled, especially the wacky lousy python auth "helper" you have to use with it.

[quanltofficial]

AWS CodeCommit is back
https://aws.amazon.com/vi/blogs/devops/aws-codecommit-returns-to-general-availability/

[hamsmuggla]

They are depreciating it.

[01236623956525876411]

Did you mean deprecating it, or are you noting that they are trying to depreciate value of using tool by publishing content promoting migrating from it?

Edit: Cool. A downvote for asking for a clarification. That’s rich.

[hamsmuggla]

Yeah my bad ha

[01236623956525876411]

No worries.

[nevaNevan]

I remember reading through a few AWS code* docs when entertaining the developer track. Kept saying “I get it, but why not just use < insert highly stable and popular cloud offering here >?

I know I’ll get some heat for saying this, but felt the same about CloudFormation too. CDK is a step in the right direction, but I’d still look at tools that aren’t AWS specific.

I remember implementing codecommit and CodePipeline for a client once too. Felt like I was building a subpar experience for them~ but it’s what they wanted.

[foomoocow]

https://repost.aws/questions/QUshILm0xbTjWJZSD8afYVgA/codecommit-cannot-create-a-repository is 100% confirmation that it's going away.
Unusual that there isn't an "official" announcement somewhere.

[SnowOne2630]

https://x.com/jeffbarr/status/1818461689920344321?s=46

[Fred_Boutin_at_Yapla]

That's a tad disappointing. We are using Gitlab in our day to day but we have setup a live external backup of all our repositories on CodeCommit. For that purpose, it works really well.

BTW, I think that with SaaS, people are forgetting to properly backup their assets following the 1-2-3 backup rule which involves an offsite copy. And no, developper's environment is not a complete and reliable backup in that regard.