AWS CodeArtifact: Lol, who needs build integrations anyway

This article is part of a series written by JFrog's Developer Advocates. The index can be found here:

JFrog Artifactory vs AWS CodeArtifact: Comparison in 10-ish parts

JBaruch 🎩 for JFrog ・ Jun 19 '20 ・ 2 min read

#jfrog #artifactory #aws #codeartifact

AWS has released CodeArtifact, an artifact repository manager, and as an employee of JFrog I’ve obviously got some opinions. My boss said I didn’t have to censor snark for this, so before I get to the point, I just want to say this:

I know naming things is hard. There are a million jokes about the difficulties of naming things in computing. AWS already has CodeCommit, CodeBuild, CodeDeploy, CodePipeline, and CodeStar, so maybe they felt backed into a corner because a convention had been established. But, y’all… there is already a completely unrelated product called AWS Artifact. Obviously this doesn’t impact the quality or usability of the tool and it’s just another example of Amazon’s tendency to forget about the existence of its own tools (understandable, there are SO MANY of them), but it’s confusing and made me chuckle so I had to bring it up.

Anyway, onwards to the point.

Do you like vendor lock-in? So does Amazon. As far as I can tell, CodeArtifact didn’t ship with any integrations for the CI/CD tools you’re probably already using and there’s no word on whether or not integrations will eventually be added. If you want to use CodeArtifact, but you’re already committed to Jenkins and moving everything over would be a bear, you’re in an awkward spot. Yes, there’s a CLI. You can still kludge something together. That’s extra work for something that should be easy, though. Your alternative is to migrate everything over to their ecosystem so you can use AWS CodePipeline, the literal only thing it integrates directly with. Either way, it’s inconvenient at best and a huge pain in the ass at worst. Maybe it’s fine if you’re starting a new project from scratch and are okay with living in Jeff’s house forever, but it’s kind of… short-sighted.

Yes, JFrog has its own CI/CD tool. It’s called Pipelines, and its integration with Artifactory is really, really smooth. We’ve got a CLI and a REST API, too. However, we also have direct integrations for the tools you might already be using -- Jenkins, TeamCity, Bamboo, Azure DevOps, GitHub Actions, and BitBucket Pipelines -- because we want you to be able to use Artifactory and everything it offers regardless of whatever else is going on in your ecosystem. Like, it’d be cool if you used Pipelines instead, but we’re not going to make it difficult to keep using the tool you already like if you don’t want to switch, and we’re not going to cut you off from some of the best features of Artifactory as some kind of punishment for choosing to stick with Jenkins.

What’s that feature I’m talking about? Build-info.

Build-info is all the information collected by the build agent, which includes details about the build. The build-info includes a list of project modules, artifacts, dependencies, environment variables and more. When using one of the JFrog clients to build the code, the client can collect the build-info and publish it to Artifactory. When the build-info is published to Artifactory, all the published details become visible in the Artifactory UI.

You get access to all of that data right in Artifactory as long as you’re using JFrog Pipelines, the JFrog CLI, or one of the six other CI/CD tools we provide integrations for. Which is six more options than AWS is giving you with CodeArtifact, and a whole lot more context for what’s going on with your builds.

Return to the index:

JFrog Artifactory vs AWS CodeArtifact: Comparison in 10-ish parts

JBaruch 🎩 for JFrog ・ Jun 19 '20 ・ 2 min read

#jfrog #artifactory #aws #codeartifact