Buildkite Reviews

I use the solution in my company to merge the codes. When somebody needs more pipelines, the tool will take that person through the setup steps, like testing the unit and CI/CD pipelines. We make some workflows, and we can track which step one can state will fail, which may be in the migration process, database migration, or when unit testing fails. We mostly use the tool for different projects; for each project, we have a different pipeline, most of which is for unit testing. With Buildkite, users can do code coverage tests as well. Suppose somebody makes changes in the code, and if there were no test cases for those, we set the minimum pass level differently for different projects. For critical ones, we also have 95 percent code coverage, and if that is not covered, the build will fail, and that code will not be deployed with the server. The tool is used for the CI/CD pipeline from merging the code. After merging the codes, it will be triggered, and all the deployments can be tracked from a center.

Mostly, my company uses AWS CodeStar as the pipeline. Using Buildkite, I think we found it easy to integrate and follow the steps associated with the product. It is also easy to track separate projects or individual projects easily.

We use it as our main CI/CD platform. Our platform was a microservice blockchain platform, and we used the solution to build our microservices and deployment.

When I started three and a half years ago, Buildkite wasn't as mature as it is today. When we first started, we had to implement many of the features that Buildkite now provides out of the box. We build our own scalable agents in Kubernetes. Buildkite now has the Kubernetes stack with built-in scalability and so on.

We eventually migrated to those features, but we had to implement many of them manually in the first place. The tool's flexibility with pipelines gave us a lot of advantages, especially when managing a huge amount of microservices.

Most of our projects involve both front-end and back-end development. We write the code and then create a file to set up our process, including specifying the tests we want to run. Before deploying to production, we need to install and configure certain things. We need something like Docker Pro, but I'm unsure about that. I'm familiar with the steps for using Buildkite for this process. We start by defining which tests to run.

Once the tests are done, we can add a button to ensure the process doesn't proceed until the test is completed or until we manually press the button. We do this because we always have multiple stages of development, like dev, staging, and production. Once the code is deployed, we test it on dev and then press the button to move it to the stage for QA testing. After QA, we press the button again to deploy to production.

If you join our team, it's very easy to learn Buildkite. We have our own boilerplate, so you can just clone it and add your configuration steps. Plus, we have documentation available to guide you through the process.

The most valuable feature of the solution stems from the fact that we could self-host Buildkite agents, and we could run them on our own AWS instances.

I am not really sure at this stage if it can be improved in any way because I haven't been using it for six months. I am sure that there would have been a lot of improvements made to the tool already since I last used it. As far as I can remember, there wasn't much that I wasn't able to do in the tool.

To make the tool auto-scalable, you need to use Kubernetes. It gets very complex if you want the tool to scale automatically. If you do manual scaling according to the demand, I think it is not too hard. Auto-scalability is an area of concern that needs improvement.

I use Buildkite on our CI/CD tool to build and deploy our services. Over the past few years, I’ve noticed that the build times have reduced due to the implementation of some testing features. The main issues we encounter are related to CI/CD.

They have great plugins, scalability, UI, and pipeline options. They also offer webhooks that allow integration with custom setups to send events dynamically.

Since Docker requires building images to run containers, we use Buildkite.

What I like best about Buildkite is its workflow management. You define YAML files to specify what needs to be done. The jobs can run based on a schedule, like a cron job, where you set it to run every night or every week. Additionally, you can set up triggers, such as new pushes to a repository.

It's quite similar to GitHub workflows. The main difference is cost, and Buildkite has some clever features for caching the build process for Docker containers. Docker containers are built-in layers, and code changes don't always mean you need to rebuild all layers. The tool can cache these layers intelligently and only rebuild the parts that need to be updated.

I work with Solenopsis, a Salesforce test automation tool. We integrate with various tools depending on the customer's requirements. 

If a customer uses Buildkite, we demonstrate how it integrates with Solenopsis for their CI/CD pipelines. The same applies to other tools like TeamCity and BuildGuard. I've used these tools to meet specific customer needs.

So, it's mainly used for automated pipelines. For the CI/CD side. It may have other features, but I've only explored it for this purpose.

It runs test execution and other tasks within Docker containers. It utilizes Docker internally.

The best thing isn't specific to Buildkite. Most tools offer similar features: they're cloud-based, making them easy to use; you have your own private space to work; and the UI is user-friendly. 

Buildkite's UI is particularly intuitive, making it simple to add steps to your pipeline. It also provides detailed logging.

We use the solution to build our continuous integration pipeline. When we raise a PR, we run test cases through it.

It is easy to integrate the solution with AWS or Google Cloud Platform. The documentation is quite helpful. The vendor has invested their time into it, and it is easy to go through it. The product logs everything. It has been very easy to trace the failures. The APIs make fetching all the build details from the logs easy.

The solution saves a lot of time running all the pipelines and test cases in one place. It also saves resources. We do not have to dig deep for changes. It saves resource time and deployment time. We deploy a product to production twice every day.