Q: Tell us a bit about what your service and plugin do. Who is it for? What are the highlights of your plugin?
A: Loader.io is a simple-to-use cloud-based load testing service. The service is designed for developers and people who need to ensure applications are performing as they should. It allows developers to perform large-scale load tests on demand, which lets them understand the scalability and performance of their applications. We realize Jenkins is the preferred build service for a lot of our users, and we know providing a way for them to implement, measure and improve application performance during the continuous build cycle is important. So we wrote a Jenkins plugin that allows load testing to be brought into the continuous build and deployment process with ease.
Q: Did you have to convince your boss/lawyers to open-source your plugin? What was the pitch?
A: No, at SendGrid our focus is always to help make developers’ lives easier, and when we can, we like to provide tools that they can hack on. Since the Jenkins platform is itself an open source project, following the same model to provide our plugin made perfect sense. In addition, we encourage others to build on our work, help improve it and ultimately make it better for everyone using it.
Q: How did you learn how to write a plugin?
A: We use the Jenkins platform ourselves, and we leverage a number of the plugins available. Having access to these and the Jenkins documentation gave us a great head start. It was an easy decision to write the Jenkins plugin for loader.io, and the Jenkins community provided both detailed instructions as well as support when we needed it.
Q: Any gotchas in the experience of developing a plugin that you want to share?
A: The overall process of developing the plugin was straightforward and simple, but we did run into some scope creep in the middle of the dev process. We found that since the platform was so easy to write for, it made us keep adding more and more features. Usually this is good, but in the case of our project, we wanted to provide the most value as quickly as possible. So we scaled back, focused on solid execution for the most important features, and are already preparing to launch a new version with the things we reserved for post v1 availability.
Q: What is the reaction from users so far?
A: The users we’ve spoken with love the plugin. In addition we’ve already gotten great feedback from some community members on “nice to have’s” in the plugin, some of which we’re already working on.
Q: What tips do you share to those who are interested in writing plugins?
A: If you have a service that provides value in the build, deployment and post deployment process, then you should be writing a Jenkins plugin. Two things are important for anyone writing a plugin: 1) be sure the plugin you’re writing is going to provide true value (if you need it yourself this is a good sign), and 2) make sure you understand the scope of the project and deliver core features and value first, then focus on some extra things. Providing a valuable plugin sooner than later will help you identify all the right additional features to include, especially when collecting live community feedback.
Some of the things we focused on early in the process were to identify the core features, and more importantly to make it very easy for users of Jenkins to install, use and interpret the loader.io plugin and results. We wanted to allow users to leverage our plugin for multiple environments and builds with system and global credentials. To do this, we decided to make use of the Credentials plugin (https://wiki.jenkins.io/display/JENKINS/Credentials+Plugin), which is a heavily-adopted plugin that provides a standardized API for plugins to store and retrieve credentials. This plugin allows our users to add and use different credentials in one single Jenkins environment. In addition, we created a new re-run feature which, when used with continuous build and testing, provides a deep view into the performance of an application over time. Finally, we wanted to bring the same UI experience users have in our environment into Jenkins, which we did by preserving the load test report model and making it function the same in the Jenkins UI. Doing this makes it easy for users to have consistency between the UIs and more easily understand the results regardless of where they’re viewing them.
It’s very easy to write a Jenkins plugin - I hope these insights will encourage you to write your own.
ps - We’d love your feedback too. Check out our newly-released Jenkins plugin for loader.io and let us know what you think.