Frustration with Jenkins is frequently raised when prospective customers speak with us. Yet, Jenkins remains the most popular CI/CD platform that is used by embedded and hardware engineers. In fact, encountering Jenkins issues was the inspiration behind our own CI/CD solution, BeetleboxCI. In this article, we will explore why Jenkins is not fit for system testing and how BeetleboxCI resolves this issue.
Most CI/CD tutorials for embedded, FPGA or ASIC use Jenkins. There are several reasons for this:
It is a story we hear a million times. A customer tries to automate their system in Jenkins. They get it working for that project, but later abandon it. This is because while Jenkins is great for simple tasks, it is not designed for the complexity of embedded and hardware development. It is primarily designed for software projects. Problems like running logic simulators, emulators or Hardware-In-Loop (HIL) testing are overlooked. It is one thing to build a single test running on one developer’s computer, it is another to scale a testing system across multiple data centres and connected devices.
At this point, a developer has two decisions: admit that Jenkins as a base isn’t good enough and abandon it or have a member of the team specialise in Jenkins to expand its functionality.
Let’s say that a team chooses to go down the expert route. That team needs an expert in their flow to make sure that their tools work with Jenkins. The team spends a few weeks training them in installation, maintenance and security. Maintaining Jenkins is a full-time job, even for a small team. In essence, this free software is now costing the company a developer.
BeetleboxCI is different. It is a zero-maintenance platform that any developer can install, maintain and use effectively. There is no need for a dedicated expert to automate complex projects.
Having a Jenkins expert comes with an even larger problem than just losing a developer. That expert is now the go-to person for everything automated. They are responsible for developing pipelines, managing projects, creating projects and learning the scripting language. Instead of CI accelerating the project, another bottleneck has been produced because everything must go through the expert. Moreover, if the expert leaves, another engineer will need to spend a few weeks learning everything.
What if instead of this, there is a CI/CD system that encourages developers to work together? BeetleboxCI is simple enough for anyone to use – developers can share the workloads of managing, editing and maintaining without any person becoming a bottleneck. Our solution is designed to allow teams to easily integrate together with no limits on users and user traceback.
A large-scale project needs a CI/CD system that can effectively manage large amounts of resources. In embedded and hardware development, tests can run for hours. This means that a team’s CI/CD system is going to need to scale with demand. In Jenkins, the expert will need to learn and use another software in combination with it. The alternative to this is to keep the use of Jenkins small and personal, but this goes against the idea of collaboration.
BeetleboxCI is designed for scaling. Simply install BeetleboxCI on a server, set its usage limits and it will automatically scale up and down. No need to manage a thousand other software. What about extra computing resources? BeetleboxCI can distribute its computing across multiple servers in the same network through generated scripts that make it easy for any developer.
Plugins look great to begin with but can quickly introduce vulnerabilities into the system. Jenkins can become bloated from all these plugins. New plugins may break previously existing pipelines or interfere with other plugins. Furthermore, teams are reliant on plugins being well maintained and developers not abandoning them.
With BeetleboxCI, everything comes in a single package. Teams don’t need to worry about clashing plugins or abandonware. Our tool provides everything needed in a single installation.
When using Jenkins, teams must pay a third party for support. BeetleboxCI provides expert support as standard. Not only answering questions on demand, but also providing training and working with teams with adopting automation for their work. Teams talk to engineers who understand CI/CD beyond software applications.
Whilst Jenkins is a powerful software, it requires a lot of time and effort to unlock that power. This often means that teams must devote an engineer to learning Jenkins and specialise in it. Jenkins goes from a free software to costing the time and salary of a developer. It adds another bottleneck to the company as opposed to removing them, which is what great CI does. Moreover, there are difficulties in scaling and using plugins. These rely on third-party software that is hopefully not abandoned.
BeetleboxCI strives to be different. It is a tool built by hardware engineers for low-level systems. As a result, it contains all the tools engineering teams need to get automating. It is designed to be used by all members of the team, not isolated to DevOp experts. It can easily grow to support large-scale projects across multiple devices. We collaborate with our customers to provide the support and training they need to automate their work.