DEV Community: Fion L

How to Make a Ruby Gem – A Developer's DevOps Perspective

Fion L — Tue, 08 Jul 2025 16:11:44 +0000

Learn how to create and publish your own Ruby gem, from skeleton generation to deploying on RubyGems.org, with a focus on the DevOps approach.

As a software developer, it's easy to find ourselves constantly building apps—web apps, mobile apps, admin dashboards—but creating a Ruby gem is a whole different game.

It’s not just an exercise in programming, but also a challenge in packaging, documentation, testing, and deployment. In this post, I’ll walk you through how I started developing a Ruby gem, with a special focus on the DevOps pipeline and publishing to RubyGems.org. This guide will grow with time, as the gem matures, so feel free to comment and contribute!

Why Build a Ruby Gem?

This project is both personal and professional. It’s a chance to step beyond app development into the world of software tooling and libraries—creating code that can be reused and extended by other developers in the Ruby community.

Building a gem is also a fantastic way to understand how Ruby projects are structured, versioned, tested, and published, which is a core skill for any serious backend or full-stack developer.

Whether you want to open-source your gem, use it across multiple projects, or simply understand how bundler, versioning, and packaging work in Ruby, this is a great learning journey.

Step 1: Prepare Your Development Environment

Before diving in, you need to have Ruby and Bundler installed on your system.

Install bundler (if not already installed):

gem install bundler

This installs the Bundler CLI globally, so you can now use it to generate new gems and manage dependencies.

Step 2: Generate the Gem Skeleton

You can now generate your gem’s scaffold using Bundler:

bundle gem your_gem_name

This command sets up a project structure including:

A lib/ folder where your main code goes
A .gemspec file which describes your gem
A Gemfile to manage development dependencies
A README.md, a Rakefile, and test setup (RSpec or Minitest)

Keep it organized—your main file should live in lib/your_gem_name.rb.

Step 3: Create a GitHub Repository

Now it’s time to version control your project. Start by creating a new GitHub repository and then connect your local gem folder:

git init
git remote add origin https://github.com/your_username/your_gem_name_gem.git
git add .
git commit -m "Initial commit"
git push -u origin main

This gives your gem a public home and enables collaboration, issue tracking, and documentation hosting.

Step 4: Set Up Your RubyGems.org Account

To publish your gem, you’ll need an account on RubyGems.org.

After signing up, RubyGems will provide a command like this:

curl -u your_username https://rubygems.org/api/v1/api_key.yaml > ~/.gem/credentials

Run this in your terminal. It will save your RubyGems credentials securely.

Set proper permissions:

chmod 0600 ~/.gem/credentials

Step 5: Understand the `.gemspec` File

Your gem’s .gemspec file is its identity card. It defines metadata such as:

name
version
authors
summary and description
files to include
Any required dependencies

Here’s a simplified snippet:

spec.name          = "your_gem_name"
spec.version       = YourGemName::VERSION
spec.summary       = "A simple tool to do XYZ"
spec.description   = "This gem helps developers do XYZ in a clean and efficient way."
spec.authors       = ["Your Name"]
spec.files         = Dir["lib/**/*.rb"]

Make sure spec.files includes all the files needed for your gem to work properly.

Step 6: Build the Gem Locally

Once your code is ready and the .gemspec file is filled out, build the gem locally:

gem build your_gem_name.gemspec

This will create a .gem file, which is a packaged version of your code.

Step 7: Push the Gem to RubyGems.org

Time to publish:

gem push your_gem_name-x.y.z.gem

Once pushed, your gem will be available at:

https://rubygems.org/gems/your_gem_name

Anyone can now install it using:

gem install your_gem_name

Or include it in their Gemfile:

gem 'your_gem_name'

Step 8: Gemfile vs. Gemfile.lock

Let’s clarify these two files:

Gemfile — declares your project’s gem dependencies
Gemfile.lock — freezes those dependencies to specific versions

When you run:

bundle install

It creates or updates the Gemfile.lock. You can think of it like a balance sheet snapshot of your gem’s dependencies.

⚠️ Do not edit Gemfile.lock manually. Use bundle update to manage locked versions.

Bonus: Development Best Practices

✅ Write tests (RSpec or Minitest) from the beginning
✅ Use semantic versioning
✅ Keep your README and inline documentation updated
✅ Use rake release to automate tagging and gem publishing
✅ Treat your gem like a product: maintain it well

Conclusion & What’s Next

This guide focused on the DevOps essentials for building and deploying a Ruby gem. You’ve learned how to:

Set up a gem project
Publish it to RubyGems
Understand its structure and versioning
Use Git and GitHub for open-source development

In the next blog post, I’ll cover the actual purpose of the gem, how I’m implementing its functionality, and how I plan to test and maintain it long-term.

Want to contribute or share your gem journey? Leave a comment or open a GitHub issue. Let’s build better Ruby tools—together. 🚀

Lost your README?

Fion L — Tue, 04 Jun 2024 17:10:44 +0000

When `git push` Breaks Your Flow: A Cautionary Tale of Lost Mojo (And How to Get It Back)

We've all been there. You're coding away, everything’s flowing smoothly, and you've just squashed a bug or added a feature that makes you feel invincible. You’ve done your git add ., dropped a poetic commit message, and now you're ready to share your work with the world. The final move: git push -u origin master.

But wait.

Red text.

Push rejected.

Suddenly, your momentum is gone.

For a second, you're staring at your terminal wondering if Git just betrayed you. You retrace your steps. Was it a rebased commit? A remote mismatch? Something about history diverging?

This isn’t the first time this has happened to me — and it probably won’t be the last. But each time, it chips away at that coding mojo we work so hard to maintain. It's a moment of panic, a slice of self-doubt, and a brief identity crisis all rolled into one.

My Mistake

In my case, I wanted to get my latest changes up to GitHub. Simple enough. So I ran:

git push -u origin master

And boom — rejection. Some upstream mismatch. I felt deflated.

So what did I do?

I panicked.

git push -f origin master

Yes, I forced the push. Yes, I knew the risks. But sometimes in the heat of the moment, logic takes a back seat and your fingers go rogue.

Did it work?

Technically, yes. The push went through. But when I opened GitHub, it was like I’d stepped through a time warp. README files and changes from previous commits had vanished — overwritten like an embarrassing childhood diary.

Finding Redemption in Stack Overflow

After a few deep sighs (and possibly a snack to comfort my inner developer), I hit the forums. I landed on this golden post which outlines the safer, cleaner steps to take when your push is rejected.

Here’s what it suggested:

git fetch origin master
git pull origin master
git add .
git commit -m "Your new commit message"
git push origin master

And just like that, my local and remote were finally friends again. No force, no loss of files, and no broken history. The key? Don’t push through the problem — pull and merge into it instead.

The Moral of the Story

The CLI can feel like a sword sometimes. Wield it well, and you feel powerful. Misuse it, and you're cleaning up history with a teaspoon. But moments like this are valuable. They teach us humility, patience, and the importance of taking a breath before smashing that -f flag into existence.

Now I Want to Hear From You

Has Git ever thrown off your coding groove?
Have you ever used git push -f and regretted it later?
Do you always pull before pushing, or live on the edge?
What’s your go-to Git strategy when conflicts or rejections arise?

Drop your stories in the comments — let’s normalize learning the hard way.