Buildkite Reviews

We use Buildkite for CI/CD during software development stages. Our environment includes separate pipelines for different tasks, such as testing, deployment etc... We have 30-40 pipelines in Buildkite

Initially, we manually configured and ran tests during deployments using Jenkins. After each job, we manually reviewed the reports to identify any test failures and then reported these to the development team. This process created a significant gap between the developers and the testing team.

To address this, we implemented Buildkite. Now, every code change triggers automated tests. We have separate pipelines for each stage of software development, including app testing, system testing, and deployment. This setup functions like a flow diagram: changes in the app automatically progress through the testing and deployment stages. Based on the results, the application is deployed to the server seamlessly.

Using Buildkite, managing pipelines becomes much easier. Each pipeline’s output is straightforward to understand, making it simple to edit configurations, Despite an initial steep learning curve, the overall process remains comprehensible. Buildkite also offers features like hooks and triggers; for instance, an action in the app can automatically trigger a pipeline. These elements can be added to specific pipelines, ensuring the entire process is automated.

When changes are made and files are modified in the repository, Automattically with the helo of hooks the Coresponding test pipeline this triggered.The hooks and the use of YAML files are particularly helpful in this process.

Since we were using Buildkite for the first time, we initially had a lot of difficulty understanding how it worked. The lack of third-party documentation meant we had to rely solely on Buildkite's documentation, contributing to a steep learning curve. Over time, it became much easier to use, though understanding certain features in Buildkite and YAML Configurations was particularly challenging at first.

Buildkite provides a comprehensive pipeline execution environment. However, in certain instances, Where a pipeline get's failed, pinpointing errors can be difficult. Therefore, when issues occur, understanding the root cause can be trickier and requires deeper analysis.

I have been using Buildkite for eight months.

We haven't face issues till now.

We haven't had any issue for the scalability part.

Previously, we utilized DevOps and Jenkins. With Jenkins, deployment was a manual process; we identified the job and validated it through reports. Now, everything is fully automated with the introduction of Buildkite. For each specific change in the application, the corresponding test pipeline is executed, and deployment occurs only if the pipeline get's passed.

The initial setup is complex. Most work for the pipeline has to be done by the development team. I'm only responsible for the test pipelines from our end.

We began with a POC for the build process, which took around one month. We started by using Azure DevOps, then transitioned from Azure DevOps to Buildkite. It took us some time to configure Buildkite and understand how it works. Eventually, we managed to have it up and running within a week. The entire POC phase lasted around eight to nine months, during which we thoroughly reviewed and refined our plans.

At least ten people were involved in the Buildkite deployment.

We are using the free version of the solution.

I was not part of the process

Overall, I rate the solution a seven out of ten.

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.

Buildkite has been pushing a lot of effort toward the plugin marketplace and plugin users, especially with the Kubernetes plugin that supports the scalability of agents. The flexibility of some plugins is somewhat limited. In the past, I used to modify the plugins according to my needs. Now, plugins support some sort of configuration or reconfiguration. I would love to see some features added in that direction and the plugin's use.

I would like to see some improvements in the hooks implementation. The hooks are amazing and give me a lot of extra flexibility in many of the pipelines, but they're still limited in some areas.

I've used Buildkite extensively in my previous job for about three and a half years.

We occasionally encounter bugs in the solution, but not many. We used to have a channel that reported Buildkite outages.

Scalability is one of Buildkite's best features, given its whole model of building your own agents and how it handles agent administration and agent lifecycle.

The solution's initial setup depends on the platform. Since I was using Kubernetes, I would say the initial setup was not very easy. That's not a limitation of Buildkite, but it is probably more related to Kubernetes. If I were just to discuss the setup with the agents, I would say the setup would be average.

Buildkite is worth the money for huge enterprises with a big enough DevOps team or operation team to handle agent management.

The solution's price model is per-user based. Since you're building your own agents, you only have to pay for the SaaS subscription, which is the user model. The solution's per-user pricing model suits huge enterprises but is expensive for small to medium businesses.

Buildkite is an easy-to-use tool. As a SaaS platform, managing agents is straightforward with the solution. Since it's a combination of pipeline and templating, some knowledge is required. However, Buildkite's documentation is really good.

The dependency between the steps is really good with failures in Buildkite. The agent's registration is a lot better now with the new stack. It wasn't so before because we had to do all this manually, and failures were harder to track. I think it's better now with the new stack. I haven't tried it extensively with the new stack, but I think it's a lot better. The dependencies and the metrics between the steps in Buildkite are quite flexible.

I would recommend the solution to other users. From a technical perspective, the flexibility of bringing your own agents is a huge advantage. From the business aspect, you don't have to worry about managing your masters. This is a huge concern for DevOps engineers using other platforms like Jenkins or Travis.

Overall, I rate the solution a nine out of ten.

I use the solution in my company to create CI/CD pipelines to handle all the services and to automate the deployment process.

Previously, my company had tried Jenkins with which we had a lot of issues since the nodes kept on crashing, making everything very slow. With Buildkite, the UI is good, but we recently moved to Monorepos, so all our service codes will be in one report. Buildkite helps manage the sessions in Monorepos.

My company uses automated scale-up and scale-down for the agents in Buildkite. Most of the time, there are on-demand agents, and it takes a longer time for an agent to kick in. All Buildkite agents run on an AWS agent, so we enable autoscaling for it. Based on the load, the agents can be scaled up and scaled down, and while they are scaling up, sometimes they just get stuck. Until the nodes don't come up, Buildkite won't run on them. The major issue has to do with the tool's scalability, especially when increasing the number of agents.

Until now, as a CI/CD tool, we have been using Buildkite, and we haven't faced any issues or gaps in it.

I have been using Buildkite for a year. I am a user of the solution.

It is a stable solution.

My company has around 80 to 100 users of the product. Users are mostly less than ten people at a time.

As the services grow, the agents in Buildkite will keep growing.

I didn't mention the solution's technical support, as most of it is covered in its documentation. I rate the technical support a ten out of ten.

Positive

Previously, my company used Jenkins.

The product's deployment phase is easier than that of Jenkins. With Jenkins, one needs to use its specific GUI language. In Buildkite, you have the flexibility to use any language.

If users use AWS or EC2 in their companies, the tool can be deployed on Buildkite's cloud services.

The product has been worth our company's investment.

Based on my company's evaluations, Buildkite is cheaper than Azure Harness but clearer than Azure Pipelines.

For a business plan, it was 19 USD per month per user.

My company has evaluated other tools, such as GitHub Actions against Buildkite. My company has evaluated other tools, such as GitHub Actions against Buildkite.

During our company's evaluation process, we had considered multiple CI/CD tools , after which we came to Azure Pipelines, Harness and Buildkite. In Azure Pipelines, there is an extra cost of parallel CI/CD pipelines, but in Buildkite, there is no such extra cost.

I recommend the product to others who plan to use it. If you use some CI/CD tools like Jenkins, GitLab, or GitHub, then there is no need to get some training in Buildkite. One can start off with Buildkite's documentation, and I feel it would be a very good starting point.

Buildkite has impacted our company's software delivery speed and cost significantly after we moved from Jenkins though there is not much of a difference, but Buildkite is a bit quicker. The ease of use of Buildkite is better than that of Jenkins. Buildkite's UI and Ux are better than Jenkins.

My company does not have any machine learning projects at the moment.

I have not seen any downtime with the tool.

I rate the tool as an eight to nine out of ten.

There are two major purposes for Buildkite in my job role. Firstly, I use it for the release of transcripts and managing deployments, including unblocking and blocking them. Secondly, I also run automation integration tests on different branches.

I mainly use what has been set up by our team members and haven't explored the details myself. 

Buildkite makes it easier to conduct deployment. When I merge a PR in Buildkite, it automatically starts the deployment process. It used to be challenging to shift code from the development branch to the testing branch because I had to follow up with multiple developers. Previously, I was dependent on the DevOps team and developers to handle deployments, but now it allows me to deploy the solutions myself. This has made it much easier for me to handle both non-production and production environments.

Buildkite has issues while creating or extending branches as only the first five builds in the user-interface can be accessed and post that one has to access the next builds by remembering branch names without pagination which can be inconvenient.

I have been using Buildkite for the past four years. 

Buildkite has been stable.

Buildkite is scalable but it has an issue while creating or extending branches. I can only access the first five builds in the user interface, post creation. After those, I need to search for the next builds by remembering branch names without pagination which can be inconvenient. However, the scalability hasn't negatively affected my work processes. 

I find Buildkite cost-effective as it has definitely increased my productivity, especially on the deployment side. It saved a lot of my time and improved data management because I can handle different environments myself now.

There were no issues faced during the integration. We've integrated unit test coverage results into Buildkite, which provides detailed information about their status. Our automation pipeline is also integrated with Buildkite, allowing us to see clear logs and track the progress of each step.

We used the solution for CI/CD pipeline, continuous integration, and continuous deployment. I used Buildkite for one of the projects in my previous company. I had to use Buildkite for just one project when I worked for a startup.

Buildkite is similar to Jenkins. You don't have to set up an agent in Buildkite like in Jenkins. In the Azure DevOps pipeline, you have to install an agent in a separate VM or maybe a Windows agent. Buildkite is like a managed service where the solution manages everything.

The solution should offer more options for installing an agent and give users the option of having a separate self-hosted or provisioned agent. The solution's user interface and user access were not that friendly.

I did not have any specific issue with the solution’s stability.

The solution's initial setup was challenging compared to other tools, maybe because we were using it for the first time. It was a new tool in the market when we deployed it.

We used the solution’s free version.

Overall, I rate the solution a six out of ten.

The tool is simple and has no learning curve. If you know YAML, you can master it. It is simple to learn. 

As a newbie, I think BuildKite has several issues. For example, it can't get the status of a PR once it's closed. The syntax is easy to use, but updating a pipeline requires administrator settings, and viewing pipelines for others isn't straightforward.

Another issue is the lack of additional support, especially with plugins. Most plugins, except for a few like Docker, aren't updated regularly on GitHub. While we haven't faced major issues, having someone actively maintain these plugins would increase confidence.

I have been working with the product for two years. 

The tool's support comes up with a solution, but its limitations affect it. 

Positive

The tool's deployment is straightforward. 

I rate the overall product an eight out of ten.