Anthony Panozzo's Blog

In this post I'll cover why I set up a local Jenkins server, and what benefits you might gain by doing the same. This post is probably most suited for developer types, but you may try it if you have many repetitive tasks.

What it looks like in action

Here is what my current Jenkins dashboard looks like:

You may notice that it seems more aesthetically pleasing than other Jenkins installs. This is due to using the Doony plugin, a series of UI improvements to Jenkins that make it much better to use. My favorite is a "Build Now" button that will kick off a build and take you to the console page to watch the build (typically a three or four step process otherwise.) This is handy for testing out new or newly modified jobs. The console output itself looks much better as well. Doony even has a Chrome extension so if you work in a stuffy office, then you can get a sexier Jenkins just for yourself.

What I specifically use it for

There are many things that need to be done to keep a computer system running at its best, and I try to automate as many of them as possible. With a local Jenkins server, I can do this and easily keep tabs on how everything is running.

One easy application is to keep the system updated. On Linux, you'd sudo apt-get update && sudo apt-get upgrade -y. On Mac, running brew update && brew upgrade nightly keeps me running on the latest and greatest. Anything that needs backwards revisions of software (databases, etc.) should have its own virtual environment or be running on the latest anyway.

This guide represents my current best understanding of how to get productive with an existing Ruby on Rails app. I currently work in a consulting / contracting role on various web development projects, and this general process would work with other frameworks similarly. I thought about the process that I go through (or would like to go through) when starting to work on an existing Ruby on Rails project, and wrote down those thoughts. Afterward, it seemed valuable enough to clean up a little and publish.

In this post I won't cover getting a legacy project's tests up to snuff. I also will not cover taking an existing Rails project and upgrading it to the latest version of Rails. There are existing resources that already cover this.

So what will I cover?

Let's pretend you are starting to work on a Rails project today and this isn't your first Rails rodeo. However, the project that you are starting on has been in development or on production for months or years. How do you quickly get up to speed to make a contribution, and how do you not break everything in the process?

This project could have been unmaintained for a little while. You could be joining up with an existing team. It could have been outsourced and in disrepair. It could have been insourced and in disrepair. :) It could be well-tested or have no test coverage. But someone, somewhere, cares about this project, or you wouldn't be working on it. Where do you get started?

Overview

The first thing to do is to understand what the project does at a high level. This might seem obvious, but still important. Questions to answer include:

• What value does this project have to the business that owns it?
• What is the primary functionality of this project?
• Where does this fit in with the company's other projects / products?
• Who uses this app on a daily basis?
• How many people use this app on a daily basis?
• What is the history of the project development?
• If the old developers are still available, can you contact them?

Once you have this information, you have a better understanding of the context of the project and those things most important to keep running.

Get Access

You can't get very far without having access to anything important. You'll eventually need access to:

• source control (Github)
• project management (Trello, Jira)
• team communication tools (Slack, Teams, Zoom)
• supplementary docs (Google Docs, Notion, wiki, Miro)
• deployment credentials (Heroku)
• error notifications (Airbrake, Exceptional, Honeybadger)
• storage credentials (AWS)
• end user message apps (Helpscout)
• performance monitoring (New Relic)
• continuous integration (GitHub Actions, Jenkins)

I would generally send out one email to whoever should have most of these and see if you can get credentials or get your account added. I would then make a document that has all of these services in one list, and then whenever you onboard a new developer you can add them more quickly the next time.

Reading the Fine Manual

After understanding the project, the next thing to do is to look at the clues previous developers have given you. Sometimes you get the dreaded Welcome to Rails documentation, but often your predecessors or teammates have left a breadcrumb trail of how to get up and running on the app.

I run the continuous integration server Jenkins on my local development machine to work as a better cron. I actually run the Jenkins LTS (long term support) version since it is designed to be more stable than the developer release line.

From the Jenkins LTS docs:

Jenkins produces a new release weekly to deliver bug fixes and new features rapidly to users and plugin developers who need them. But for more conservative users, it's preferable to stick to a release line which changes less often and only for important bug fixes, even if such a release line lags behind in terms of features.

I'd rather have stability than blazing edge features for something that is just supporting infrastructure. Since I am using a Mac, it would be nice to install this using Homebrew. The homebrew-versions keg has a version of this, so you can install it from there with:

This blog used to run on WordPress, but I was not entirely happy with it. I changed it to use Octopress (an extension of Jekyll) and I enjoy the writing workflow better now.

WordPress is a content management system, and as such, it does a whole lot of stuff. WordPress has a ton of built-in functionality and is well-tested. With plugins, you can add many things: from shopping carts to calendars to image slide shows. Other plugins can give you detailed permission models and auditing for posting or other complex functionality.

Advantages

I didn't like WordPress for blogging for a few reasons (many of them very specific to my workflow.)

I prefer writing with Vim, and no WordPress functionality was going to easily replace this tool. This alone would probably be enough to get me to switch. Typically what I would do would be to compose a post in Vim, and then copy that into WordPress, do a little previewing to make sure everything looked good, then schedule the post for some future date.

Using a static site generator like Octopress or Jekyll enables me to use git. Git tracks detailed version changes across the entire blog (not just the posts). It also lets me work locally and then easily deploy when I am back online or finished. With WordPress I would have to connect to the server to be able to write. I can now even preview locally, something I could never do without an internet connection. Further, I can set it up so that preview updating happens whenever I save the file, so I can see how changes look in near-real time.

I've been doing a fair amount of flying in the last year, and Southwest is currently my favorite airline. In this post I will list reasons why Southwest is the best (in order of importance) and one thing I'd like to see improved.

Biggest Benefits

Liberal reschedule policy

Probably the biggest benefit to me has been Southwest's liberal flight rescheduling or cancellation policy. On many other airlines, changing or cancelling your flight reservation (whether it is days or months away), will cost you hundreds of dollars. Have something come up at the last minute? Well, you're out a hundred bucks to change your flight by an hour or two. You can pay much more for a refundable ticket as well.

Southwest does not have this restriction, so even if you pay a little more for your ticket, if you use this option one time, you are going to come out ahead. Worst case, if you cancel, you get a credit to apply to future Southwest flights.