AWS CodeBuild Reviews

My use of AWS CodeBuild is focused on the CI/CD part, which stands for continuous integration and continuous deployment. Basically, we write the code and then commit it into a repository, which could be GitHub or GitLab or something similar. Some of the database changes that we have to do are uploaded into an S3 bucket. From the S3 bucket, we can configure AWS CodeBuild to apply those changes into the database. AWS CodeBuild is mainly used in the CI/CD process for automated deployments. It can deploy into pods, Kubernetes structures, or ECS, or anything else. I have used it for automation deployment purposes, though it may have some other features as well.

AWS CodeBuild can support multiple build artifacts, which is beneficial. If we have to deploy something in the database or deploy something in containers or virtual machines, it supports all those things.

I find the deployment feature and running the YML files most useful in AWS CodeBuild. I have used the buildspec.yml for customization. It has inbuilt template YML files, and Build dispatcher is one of them. Overall, it is mainly used for the deployment and CI/CD part. It has certain templates we can use, and we can create our own templates as well.

I have integrated AWS CodeBuild with GitHub or GitLab in any of the repositories. It is configured with GitLab to AWS CodeBuild, and whenever there is a commit, the GitHub YML file triggers that flow. It then gets executed in AWS CodeBuild and gets deployed in the respective server or containers.

AWS CodeBuild's support for popular languages and tools has enhanced my productivity. It supports the three most popular stacks that are in the world: the Python stack, the Node.js stack or framework, and the Java framework. There are other technology stacks such as Ruby on Rails. It supports what I know of as the ten most popular technology stacks, which are more than enough. There could be some newly evolving language or technology somewhere that it does not support, but that is acceptable. It evolves over time.

I assess the impact of AWS CodeBuild's fine-grained IAM permissions on the project's security as very vital. IAM plays a very vital role in terms of providing access and everything. Whatever component there could be around fifty to sixty service types in Amazon, including everything such as Postgres, RDS services, virtual machines, ECS containers, EKS containers, and S3 buckets. There could be more than seventy services that AWS provides. In IAM, including AWS CodeBuild and AWS Bedrock, all these things are included. IAM basically creates permission sets and then assigns those permissions to users or user groups. IAM basically controls everything in terms of who can access and all those things. It is integrable with every component within AWS, not only AWS CodeBuild, but we can integrate IAM with everything that is present in AWS.

My recommendation for AWS CodeBuild to make it better for the next release would be something within AWS CodeBuild which can support the repository functions as well. It may not be as powerful as GitHub Actions, but it provides a very competitive price compared to GitHub Actions. GitHub Actions, if you want to use the YML CI/CD pipeline, gives a free tier of around three thousand hours per month. AWS CodeBuild is a little more expensive than that. However, if it supports the repository function as well along with it, then it will be a complete package. Everything would be in AWS, including the code versioning, code commit to the code infrastructure, to the code database, to the networking, and how the applications are accessed. Everything would be in one place, which would be very helpful.

I believe AWS CodeBuild is a bit expensive because GitHub provides around three thousand minutes free, plus it has the free repository function as well. At the enterprise level, it charges maybe around nineteen dollars per user, though I do not remember exactly. In terms of AWS CodeBuild, I believe it is a bit expensive because it is providing only the deployment features. It is not providing the repository. In that comparison, I would say it is a little bit expensive.

I have not faced any problems or issues with AWS CodeBuild yet. To be honest, I have been using AWS CodeBuild for not a very long time, approximately one point five years as I mentioned, but I have not encountered anything yet. If the region goes down, for example, around five or six days ago, the US East-1 region went down and it came in all over the news everywhere. Those problems are global outages. Apart from those problems, I do not see anything. I have never come across anything.

I have contacted AWS support many times in the past. I think the support AWS provides is very good compared to other cloud service providers such as Microsoft Azure or Oracle. I found AWS support more comprehensive. They have highly technical people who are supporting enterprise customers. I believe AWS is more useful compared to the other clouds. My rating for AWS support would be ten.

Positive

The setup of AWS CodeBuild is straightforward. It has very detailed documentation.

My recommendation for those planning to use AWS CodeBuild would be to study all the features. Even these days, if the knowledge base is too much, you can always take help from AI. Leverage AI, study all the features, and use it to its full extent. If you use it to half extent or maybe partially and you are taking some features of it, then what happens is you end up paying more and you are not leveraging all the facilities that it has. My recommendation would be to use it to its full extent as much as possible if you are planning to use it. I would rate this review a nine out of ten.

I have been working with AWS CodeBuild for about two years now. I am working with AWS CodeCommit. AWS CodeBuild integrates with AWS CodeDeploy and AWS CodeCommit in a sequential pipeline. When we trigger something with AWS CodeCommit, the consecutive steps are triggered afterward.

AWS CodeBuild operates between AWS CodeCommit and AWS CodeDeploy. After code is committed to AWS CodeCommit, if the build is automatic, it triggers the pipeline. The pipeline consists of AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy. AWS CodeBuild manages our code execution for various languages including Java, NodeJS, Android, Kotlin, or others. It helps us build the code and can also assist in deploying that code through AWS CodeDeploy.

AWS CodeBuild offers environment variables, also known as project secrets. These can store GitHub tokens for Git repositories or certificates for iOS/Android builds. The environment variables feature includes functionality to encrypt and decrypt secrets within AWS CodeBuild itself. The permission structure operates through IAM policies, ensuring least privilege access and preventing unauthorized usage.

AWS CodeBuild's support for a wide range of programming languages and build environments benefits development teams significantly in terms of productivity and ease of use. There are extensive libraries of code structures available, making it a universal pipeline. All programming languages I have worked with are supported in AWS CodeBuild, eliminating the need for alternative deployment services.

The service supports iOS builds, Kotlin, Java, NodeJS, and ReactJS. AWS has made it accessible to all languages, allowing developers to simply open the console and trigger builds. AWS manages all the background server operations for building or deploying code. For standard builds such as ReactJS or Java, a Linux or Ubuntu server suffices. AWS provides its own operating system for these purposes.

For builds requiring physical servers, such as Apple macOS server, AWS rents Mac minis specifically for iOS and SwiftUI builds. While this incurs higher charges, it demonstrates AWS's commitment to providing comprehensive solutions for all use cases.

The servers used for macOS and iOS builds are limited in availability, operating only in US East 1 and East 2, and US West 1 and West 2. This geographical limitation causes latency issues and extended build times for regions such as India, impacting production efficiency. However, other server types are available across all regions without such limitations.

When starting my work, I considered alternative technologies to AWS CodeBuild. CircleCI was one option, offering 30,000 credits for error handling and troubleshooting with its own YAML structure similar to AWS. Additionally, my team leader identified GitHub Actions as another solution that supports macOS builds and triggers. Both CircleCI and GitHub Actions serve as viable alternatives to AWS CodeBuild.

AWS resources are organized according to different environments including dev, stage, QA, prod, and pre-prod. For developers working in the dev environment, we configure the setup and provide appropriate permissions to the development team.

The system operates through automatic triggers following PR merges and code reviews. When code is pushed to the main branch from a developer's branch, it triggers AWS CodePipeline. AWS CodePipeline then builds the code using AWS CodeBuild based on specified parameters.

Deployment occurs through buildspec.yml files, which determine the destination path for deployment, whether to a server, S3, or Amplify. This streamlined structure ensures smooth operation in production environments.

The return on investments is favorable for normal builds, excluding macOS. These builds follow a pay-as-you-go structure, charging only for actual usage. The entire AWS CodePipeline system works effectively, though the reserved structure poses challenges for mid-size and startup companies who must bear costs regardless of usage. There appears to be a gap between AWS and Apple that needs resolution to make it as accessible as other languages or servers.

The cost structure is affordable for most builds except macOS servers. Standard builds can utilize AWS EC2 servers for background operations. However, macOS or iOS builds require physical servers maintained by Amazon. Triggering these builds essentially reserves the server for 24 hours, resulting in higher costs compared to readily available servers. Reserving a physical macOS server such as a Mac mini incurs substantially higher costs than standard server options.

AWS CodeBuild integrates with CloudWatch. This integration can be established during the creation of AWS CodeBuild and AWS CodeDeploy. When building a pipeline, the buildspec.yml file must follow specific AWS structure changes. While it is fundamentally a YAML file, it requires AWS-specific modifications.

For mobile application development with macOS builds, several options exist. Prior experience with AWS CodeBuild involved different builds and languages, including Java, React, and NodeJS web applications using Jenkins. For those less familiar with macOS structure in AWS CodeBuild, using a macOS server might be preferable. To optimize costs, servers can be turned off after use to avoid reservation charges.

The AWS CodePipeline components can function independently. With GitHub repositories, connections can be established to pull code, build it, and specify deployment locations through YAML code. Base64 encoding is required for secret values in environment variables, which can be cumbersome without Secrets Manager. Using multiple secret storage methods can complicate debugging processes. GitHub's transition to mandatory token authentication has also presented connection challenges.

On a scale of 1-10, this solution receives a rating of 9.

Positive

Right now, we are testing a small verification using AWS in the UK. As a cloud engineer, I regularly depend on AWS to speed up our applications, and we do this mostly using AWS services like EKS. Additionally, we use AWS CodeBuild to automate tasks such as setting environment variables and pushing code to the ECR repository, after which we deploy applications on EKS.

One of the main features I value in CodeBuild compared to previous experiences, like using Jenkins, is its ability to handle tasks automatically with AWS, requiring only proper setup of the check file. Remaining tasks are managed by CodeBuild itself. Furthermore, CodeBuild enables logging features during different phases, storing the logs in CloudWatch. This automatic scaling based on AWS attributes simplifies things significantly. The support team is also a beneficial resource, providing assistance in a friendly manner whenever there are issues.

One of the main challenges is that if the environment is not set up properly, it will result in issues such as image errors. It's crucial to have accurate environment configurations to avoid such problems. During the build stage, we often face time issues that cause delays, which can be troublesome.

I have been using CodeBuild for approximately one year.

I have not faced any stability issues with AWS CodeBuild. The only challenge I encounter is related to environment variables during the build stage, specifically when pushing images to the ECR.

Scalability is a great feature with AWS CodeBuild. After deploying applications, the service automatically scales up and down according to our AWS needs using load balancing. This makes managing applications much easier without significant interruptions.

Our company has an enterprise account, allowing us easy access to AWS support. They're excellent at addressing issues in a friendly and efficient manner, helping us to resolve any account-related concerns quickly.

Neutral

Before using CodeBuild, I was using Jenkins for deploying applications, which felt complicated due to the constant need to observe updates and changes.

The initial setup of deployment is one of the most complex aspects. Commands need to be run to update clusters and node groups, however, after this process, everything becomes smoother.

The cost of using AWS CodeBuild is surprisingly reasonable compared to other solutions.

Before using CodeBuild, it is essential to ensure you have all necessary permissions and understand the services for connectivity with AWS. Without proper permissions, managing CodeBuild effectively can be difficult. 

I rate the overall solution as a seven out of ten based on my experiences.

We have been using Amazon EKS, Elastic Kubernetes Service, ECS, and EKS for containerization. For databases, we have been using RDS, Relational Database Services. We also use CodeBuild and CodeCommit for maintaining our code repository. Additionally, we have worked on a small project for migrating a bulk amount of data into AWS with the help of a migration service.

CodeBuild supports various platforms and coding, which offers an advantage. I have also been using AWS CodeBuild for our CICD pipeline, where we have source build, test, and deployment. 

We integrated AWS CodeCommit for repository management, and we transitioned from using Maven for the build process to AWS CodeBuild. Additionally, for testing, we use Selenium, and deployment occurs on EC2 AWS servers.

We had integration issues with a tool called Octopus Deploy while using CodeBuild. AWS support helped us resolve it, however, it could be better.

I have been using AWS CodeBuild for four plus years.

The stability of CodeBuild is quite fine. We never faced any kind of storage-related issues, and our code is always available, triggering new builds when configuring new environments.

CodeBuild's scalability is quite good. We never faced any storage-related issues, and our code is always available for triggering new builds whenever we configure new environments.

AWS support helped us resolve integration issues we had with Octopus Deploy. Their support has been rated an eight out of ten.

Positive

We were previously using Maven for the build process before moving to AWS CodeBuild.

Regarding pricing, AWS services are quite expensive compared to open source tools like Git that are available for free.

I would recommend CodeBuild for people who already possess knowledge of other build tools like Maven, as it requires some level of expertise to work with. 

Overall, I would give AWS CodeBuild a rating of seven out of ten.

We have it on various client projects and we rarely use it individually. It forms part of an entire pipeline committed in CodeCommit along with all the customers' code. Then, it's picked up by CodeBuild in the pipeline to build the site, update the sites, and update the services with CloudFormation scripts. This could be for a simple serverless website or more advanced projects where we need to build an image in Java or .NET.

The most important feature is that it's self-contained in an AWS account, and it's all linked to the customer's AWS account. You manage the identities through the AWS account, and AWS looks after the security and availability of the service. That's the key.

The front-end interface and the management are somewhat challenging, and there's a lot of space for improvement. Customers are expecting the graphic user interface to be at the level of GitHub or GitLab, but it's really not. It's quite a struggle with that part of the service.

We have been using it since inception, probably starting in 2015 or 2016.

It is difficult to say whether issues were because of resource limitations or waiting times as such. I would rate it a six out of ten due to some intertwining issues with processing speed.

Scalability has been satisfactory, although there are issues with CodeBuild having insufficient CPU allocated compared to other offerings like Bamboo from Atlassian, which allows more processing power. This limitation means that sometimes we can't get more than what's allocated by AWS.

For enterprise clients, especially large groups who have multiple country deployments and multi-region setups, it makes sense to have it in the AWS ecosystem.

I'd rate the solution five out of ten.

I use the solution for continuous integration.

The integration of the product with our ecosystem is very good. X-Ray and CloudWatch metrics are already integrated. If anything happens, we can see everything immediately. If it were Jenkins, we would have needed an instance to run it and a server to show the results. From that, I would have had to do a configuration for getting the logs to CloudWatch. The solution provides good integrations. We use CloudWatch metrics for logging.

The product must provide more integrations. It is a replica of Jenkins. We have a management overhead. When I build artifacts stored outside the S3 bucket, it will have additional charges on the storage volumes. If we use S3 buckets regularly, it is fine. However, when we store somewhere else, it will be an issue. There is no persistent storage or preservation of workspace between the builds. We must fix the dependencies every time, even if the dependencies are the same. It is unnecessary.

I have been using the solution for the past one and a half years.

The stability is good. We do not face too many crashes like Jenkins. Occasional crashes happen.

I like the tool’s scalability. I rate the scalability a seven out of ten. It is scalable enough. AWS is very good for scalability. If the same build is executed with the same dependencies, it will re-execute everything. It has dynamic scaling. It is very helpful. We can automatically scale. We have more than 100 users. We are a service-based organization with different clients.

The technical support team is good enough. Whenever we raise a request, we get the preliminary documentation or a proper response from the support team. The speed of response depends on the issue we raise. AWS support is good compared to Azure. The response might be slightly delayed no matter what tier we belong to, but we get responses within the SLA. Azure’s support team takes a lot of time if we have a lower-tier subscription. I rate the support team an eight or nine out of ten.

Positive

Earlier, we used to work with Jenkins. We had to do a ton of integrations. We switched to CodeBuild because it is flexible.

The initial setup has a learning curve. However, it is better compared to Jenkins. AWS has a standard flow for any product. I'm comfortable with it. The setup is not as easy as open-source tools, though.

The pricing is okay. Jenkins is not costly, but we must pay for the underlying infrastructure. The infrastructure is continuously there for the entire duration. In AWS CodeBuild, we don't have a dedicated infrastructure. However, it works. The bill is almost the same. We can configure better instances if we need it to be faster.

I will definitely recommend the tool to others. In terms of overall cost, it costs the same as Jenkins. Some think that Jenkins would not cost much since it is open source. Though the software doesn’t cost, the underlying infrastructure will cost us. We also need resources to manage the tool. Overall, I rate the product an eight out of ten.

Our main use case for AWS CodeBuild is building our microservice-based application in the IT industry.

The tool is used to build and test code. I find its biggest advantages are elasticity and reliability. We can easily assign as many computing resources as needed to build our code, which is much simpler than traditional methods that require server upgrades. It's a serverless tool, so it's very flexible and elastic.

Integration with other AWS services and third-party tools like GitLab or Jenkins is simple. I haven't faced any challenges using AWS CodeBuild. It's straightforward and communicates well with CodeCommit for code storage, or it can fetch code from GitHub.

For improvement, I'd suggest more build instance-type options. There's a big jump from 15 gigabytes of RAM to 150, and I'd like something in between as the larger option is too expensive for our needs.

I have been working with the product for four years. 

The solution is highly stable; I rate it a ten out of ten. 

The tool is very scalable, and I rate it a ten out of ten. More than 30 developers on our team indirectly use AWS CodeBuild in our development process. Developers push their code to CodeCommit, which goes through the CodeBuild pipeline.

We're very satisfied with AWS support. We're on the Enterprise plan, which I'd rate ten out of ten for support quality.

Positive

Setting the tool up is relatively easy—I'd rate it eight out of ten—but some AWS knowledge is required.

AWS CodeBuild is part of a full CICD suite in AWS, working alongside CodeCommit, CodeDeploy, and CodePipeline. It's a cloud solution where CodeCommit stores the code, AWS CodeBuild builds it, CodeDeploy deploys it, and CodePipeline configures all these steps as needed.

The tool saves us money as it's on-demand, only working when triggered.

AWS CodeBuild is free. We only pay for our code's compute resources during the build process. For example, if our code takes ten minutes to build, we only pay for those ten minutes of computing time. CodeDeploy and CodePipeline are free because they're serverless and don't require computing resources. CodeCommit has minimal costs for storing code.

If you run AWS applications, I advise those considering AWS CodeBuild to use the entire CodePipeline Suite (CodeCommit, AWS CodeBuild, and CodeDeploy). It's a great CICD tool compared to third-party options. I've used GitLab and Jenkins before, and while they're good, I prefer AWS solutions because they're reliable and fully managed, offering the best SLA in the market.

I always recommend going with native tools when possible. Overall, I'd rate AWS CodeBuild ten out of ten.

We are creating pipelines with the help of the solution. We need to do some testing and deployments over our web server. We create a new bucket in which we create a CI/CD pipeline and put our deployments into it. CodeBuild deploys it through GitHub on the target server.

If we face any issues, we can find out where the issue is. We can check it on the script. We can easily do debugging or troubleshooting. We had development projects. We are using CodeBuild for five to ten applications. We deploy them first in the development environment. After the Sanity tests and the UAT, we deploy them on the production environment. The integration with other AWS services has streamlined our workflow. It is similar to any other product. We must define the roles. It is easy to give permission to other services.

The deployment fails sometimes. We need to reset the pipeline to do the deployment.

I have been using the solution for the past four years.

I rate the tool’s stability an eight out of ten. Some applications must be checked end-to-end because Java does not work sometimes, and we do everything manually and restart. We must check whether all parameters are correct on the scripting side and whether there are any dependencies we must know about.

We can create multiple pipelines. If we need multiple deployments for multiple projects, we create multiple pipelines to do the deployment. We have 50 to 80 users.

The support is good.

Positive

The initial setup was difficult the first time since we had to configure it end-to-end. We got some errors. After the configuration, we did not face any major roadblocks. The deployment took five to ten minutes.

Apart from Jenkins, I love to use CodeBuild.

I will recommend the tool to others. We must know the dependencies in our projects, the services we need to deploy, and the different things needed in the scripts. We must do the IAM configurations on AWS before initializing the pipeline. Overall, I rate the products nine out of ten.

A normal use case for CodeBuild is to use it with the code pipeline for proper CI/CD. Normally, it's used to make a CI/CD pipeline.

A valuable feature is the support for third-party repositories such as Bitbucket, GitLab, or GitHub. Another valuable feature is the logging feature, which saves all the build logs in CloudWatch. This makes it easy to track or trace the logs of all the builds and helps in the troubleshooting process.

Notifications could be added, or SNS integration could be included so that notifications can be received on every build, whether the build fails or succeeds.

I have used the solution for around three to four years.

It's a very lengthy process to set it up, but when it's set up, it never experiences any outages or downtimes. It is highly stable and never gets broken again after the initial setup.

AWS is so flexible that it works with all providers, which becomes very helpful in scaling. Generally, it's used in the software development process, and in the development and deployment processes, so the scalability supports different workflow volumes.

I rated the setup seven out of ten as it's a long process. Everything is very simple, so there is no big hassle. That said, it's a very lengthy process.

CodeBuild doesn't have a price for itself; it is included in a bundle with different services. I would rate the cost of this bundle, where CodeBuild is included, as five. It's rather affordable.

AWS CodeBuild is a simple service, and it doesn't need any specific advice or rules to follow. Everything is properly defined while configuring CodeBuild, and AWS can be used as optional documentation.

I'd rate the solution ten out of ten.