Share your experience using AWS CodeBuild

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.