OrbWritingTips.png

In my last post, I went over the process I went through building my first orb, and explained why it’s such a great option for those wanting to make a contribution to the open source community. In this post, I’d like to sum up the most important things I learned while writing the orb, to give some guidance to those who may want to give it a try (and I really recommend you do)!

So, ready to write an awesome and popular orb for that sweet open source contribution sauce? Keep these considerations in mind:

1. Solve a problem: As with anything in programming, developing, and inventing, the main goal is to solve a problem or improve the experience of the user. Sometimes that might just mean connecting “this thing” to “that thing” (better known as integrations). Our AWS CLI and S3 orbs are a great example of implementing a service as an orb.

Your favorite CLI tool or API could potentially be made easier to install and use via orbs. You can even implement functionality that wouldn’t otherwise exist (yet!) without orbs.

In my case, the desire was to offer more modular and better integrated Slack notifications. Many of our users rely on Slack notifications to receive updates on successful or failed jobs ran on CircleCI, an important tool to know if anything has stalled your development pipeline.

2. Give freedom to the user: The beauty of a great orb is simplicity with utility. When creating your own orb, it’s important to find a balance between making the tool easy to use while keeping it general enough that it can be adapted to fit most users’ needs. End users have an excellent way of using tools and products in ways you may have never dreamed of. Making your orb generic and extendable means it can be of more use to more people.

Pointing to the Slack orb again, one of the parameters is the color of the message sent. By default, the message will contain a grey outer border. The option to change the color allows the users to customize their experience: they might choose to differentiate between types of problems, or maybe use different colors to indicate different projects or teams. It’s truly up to the user.

3. Create a development pipeline: Utilizing Workflows in CircleCI will allow you to not only lint and publish your orb as mentioned before, but also test it in multiple use-case scenarios. Just as with any other piece of software, we want to be able to test our code as we make changes–because changes sometimes mean breaking things. Knowing your code is working properly before launching gives you the best chance at creating a popular and trustworthy orb that will provide value for users without causing any errors.