Review everything, not just code

Code review is a staple in many engineering cultures. The benefits to putting your code up for your teammates to scrutinize and critique are numerous. There’s the satisfaction of showing off your work to your peers and the comfort in knowing that any obvious flaws or bad design choices will be caught before they affect others.

Unfortunately, code review is often where thorough review ends for many teams. UI changes, mockups, PRDs, documentation, release notes, icons, and other visual components critical to a project are not always as closely inspected, or at least are not done so as part of the existing code review process. By leaving these out, or doing them out-of-band (e-mail, in-person reviews), or even by going through entirely separate tools, there’s the risk of missing and tracking valuable feedback.

Through Review Board and Power Pack, you can review those just as easily as code. No new tools to learn, no loosely tracked discussions. Here’s how.

File attachments on Review Board

In Review Board, you can attach any type of file to a review request and review.

There’s built-in support for general text-based file attachments, Markdown files, and images. Extensions can supplement that with support for reviewing additional file types, like PDF. Unsupported binary files can still be reviewed by downloading the file and then leaving a comment on it.

All you need to do to attach files is to drag them (as many or as few as you want) from your file manager right onto any new or existing review request.

Or, if you’re a command line junkie like I am, check out tip #3 on our 5 tips for RBTools.

You’ll be able to try these yourself on our demo page.

Reviewing screenshots, icons, and other images

If you’re developing a UI for your application, make sure your fellow engineers or your usability team sees it before your QA team or users do.

Take a screenshot, or two, or a dozen. Show off all the changes you made, the new dialogs, the icon updates. Upload them as part of your code change so that your reviewers can see the impact of your code. Your reviewers will then be able to go through your screenshots and review them just like source code.

Reviewing images is easy. Simply click-and-drag over an area of the image, like you’re selecting it. A comment window will pop up (just like for code). Enter some text and save it. When the review is published, you’ll see that section of the image in the review, and discussion can begin.

Image Review

Reviewing plain text files

As developers, we love plain text. We have one-off bits of test code not fit for the tree, we have log files, development notes, test runs. All kinds of things that your reviewers may find useful when looking at your code.

So post them.

Reviewers will see a nice display of the text similar to what they’d see in the diff viewer. If Review Board recognizes the file type, it’ll even syntax highlight it for you, which is great for files like XML.

Text Review

Reviewing Markdown files

Markdown is a pretty popular way to write rich, formatted text in the comfort of your 1970s text editor. I’m using it right now to write this post, in fact, and you may be using it for your documentation or Wiki pages.

During review, we automatically render your Markdown so that you can see how it looks. Reviewers can leave comments right on the rendered copy or on the raw Markdown text.

Want to see this in action? Check out our demo.

Markdown Review

Reviewing PDFs or other documents

Product managers and doc writers generally aren’t writing Markdown or code. They’re working in Word, Excel, Power Point, or something more specialized. When they want a review of the latest PRD or section of the manual, they probably just e-mail it out to you, and you probably e-mail them back some replies. Yuck.

Instead, convince management and your doc writers to export their documents as PDF, and then upload them to Review Board. If you have Power Pack installed, or you’re an RBCommons subscriber on a Medium plan or higher, you’ll be able to read through the PDF and comment on any part of it.

This works very similarly to screenshot commenting. Click-and-drag to select a region, and leave a comment. That section will appear along with your comment in the review, just like with code or screenshots.

It’s a much better way of tracking all the feedback around the design or documentation of your product.

You can see what PDF review is like over on our demo page.

PDF Document Review

So in conclusion…

Review all the things!

Read More

5 Tips for your RBTools workflow

If you’re a Review Board or RBCommons user, you’re probably familiar with RBTools, our handy set of command line tools for working with Review Board. (If you’re not using RBTools, I’m going to tell you how to get started with it in a bit.)

You’re probably most familiar with rbt post, or post-review in older versions. This is the tool that helps you quickly get a change onto Review Board, or to update an existing review request. It’s pretty handy, but how much do you really know about it? Or about the other commands included with RBTools? (Yes, there are others!)

I’m going to show you five of my favorite tips and tricks for RBTools that you may not know about.

5. Opening a browser after posting with rbt post -o

When you run rbt post, you usually get something like this:

$ rbt post
Review request #123 posted.

https://reviewboard.example.com/r/123/
https://reviewboard.example.com/r/123/diff/

Those links for opening the review request or diff are useful, but you can save yourself a step by having RBTools open your browser for you. Just pass -o to rbt post, like so:

$ rbt post -o

Your browser of choice will open, ready for editing. Want to do that automatically, every time? Add this to your .reviewboardrc in your home directory:

OPEN_BROWSER = True

4. Check your open review requests with rbt status

At some point or another, you’ll want to see what review requests you have open, either as a draft or currently pending review. I myself need to do this at times to help me remember if I’ve already posted something for review.

Sure, you could dig through the dashboard and check. That works great, but it means leaving the command line. That’s where the rbt status command comes in:

$ rbt status
   r/6676 - Add release notes for Review Board 2.0.12.
   r/6258 - Add release notes for Review Board 2.1 beta 1.

rbt status will show you all open review requests for the current repository – their IDs and their summaries. Pass --all and it’ll show you all open review requests across all repositories.

3. Attach files to review requests with rbt attach

Review Board makes it pretty easy to drag-and-drop files onto a review request in order to quickly upload them, but it does mean having the file manager and web page open. If you’re a command line junkie like me, you’d probably rather avoid that as much as possible.

rbt attach will let you upload a file to a review request with a single command. Just give it the review request ID, the file to upload, and an optional caption, and you’re done.

Let’s try it.

$ rbt attach 123 screenshot.png
Uploaded screenshot.png to review request 123.

Want to give it a caption?

$ rbt attach --caption "UI screenshot" 123 screenshot.png

2. Apply a review request’s diff to your tree with rbt patch

If you’re an open source developer, or you like to thoroughly test other people’s patches as part of reviewing their code, then this tip is for you.

rbt patch pulls down the latest patch (or a specified revision) from a review request and applies it to your tree. It can even create a commit for that patch, if using Git or Mercurial, by running rbt patch -c.

$ rbt patch -c 123
Changes committed to current branch.

We use this when accepting contributions from our own Review Board server. After a thorough review, we run rbt patch -c, edit the commit message as appropriate, and push it.

As a bonus, this will append a Reviewed at <url> line to the bottom of the commit message. If you’re using repository hooks to auto-close review requests (admins, see the “Hooks” link next to a repository in the administration UI), pushing this commit will take care of closing that out for you.

1. Easily update review requests with rbt post -u

If you’ve been using RBTools for a good long while, you’re probably used to passing -r <ID> to rbt post, in order to tell it which review request to update. This means having to look up the ID and making sure you don’t type it wrong.

In RBTools 0.6 or newer, we have a much simpler solution. Just pass -u. RBTools will automatically find a matching review request, asking if it’s not completely sure it’s a match, and update it for you. Let’s compare:

$ rbt post -r 123

vs.

$ rbt post -u

It’s much nicer. Get in the habit of using -u. It’s the wave of the future.

What if I’m not using RBTools?

Use it!

Seriously, RBTools is the best way to get the most out of Review Board. You can follow our installation instructions to get started. We’ll soon be announcing new installers to make this easier.

Learn more

The RBTools documentation is a great resource. You can learn about all the RBTools commands, our Python API for interfacing with Review Board, configuration options, and more.

We’ll be posting a new batch of tips and tricks for RBTools soon, plus some advanced Git and Review Board tips.

If you’re not already on our mailing list, subscribe today to keep up with the latest releases, tips, and strategies.

And now, we’d like to leave you with this:

Isn't it cute?

Read More

Auto-closing review requests when pushing changes

We’ve launched a new feature today for simplifying your code review workflow.

If you’re using GitHub, Bitbucket, or Google Code, RBCommons can now automatically close your review requests when you push your commits to your repository, making use of the service’s “post-commit” hooks. You’ll no longer need to click Close -> Submitted, saving time and keeping your dashboard clean.

 

Usage is simple

Once you’re set up (and we’ll go into that in a minute), all you need to do is include the following in your commit message:

Reviewed at https://rbcommons.com/s/<your-team>/r/<id>/

Or:

Review Request #<id>

Just commit, and your review request will be automatically closed, along with a message containing the commit revision and which branch it was committed to.

 

Setting this up

Setup depends on which service you’re using for your repositories, but we’ve worked to make it pretty simple.

We’ve added some new buttons to your Team Administration -> Repositories page. You’ll see a “Hooks” button next to any supported repository. Click that, and you’ll see instructions on turning this feature on for your repository. In just seconds, your repository will be set up!

This feature is still new, but has been undergoing testing for several weeks. If you hit any snags, let us know and we’ll help get you going.

Read More

RBCommons and this week’s security news

This has been an interesting week on the Internet, security-wise. A vulnerability in the Bash shell (named “Shellshock”) was announced that allows remote execution of code on unpatched servers with certain configurations. Separately, an undisclosed vulnerability in Xen forced AWS and Rackspace to announce mandatory reboots of many of their customers’ servers. (See Amazon’s announcement and Rackspace’s announcement for more details.)

We’d like to give an overview of how all this is affecting RBCommons and, in turn, you.

We keep a close eye on all security updates available for the software and libraries we use, and are quick to patch our servers as fixes roll out. We’ve also performed many tests to ensure that malicious Shellshock HTTP requests do not impact us. Your data is safe.

Some of the services we use were affected by the mandatory AWS and Rackspace reboots. Earlier today, our mail provider, Mailgun, was temporarily down during the outage, which may have resulted in missing or delayed e-mails for those working on Sunday.

We’ve had a few rare DNS lookup failures, resulting in errors when visiting pages or otherwise interacting with RBCommons. There have only been four so far, and are temporary. If you see a random error loading a page, please just try again. We know this failure has affected a number of other AWS customers as well.

Tonight at 11PM PST, Amazon is scheduling some of our servers for a 6 hour maintenance window. This isn’t the first set of our servers to have undergone the mandatory maintenance, and we aren’t expecting any interruption to RBCommons during this time. However, we may be running at reduced capacity for about 20-30 minutes. We will be monitoring things closely.

If you are repeatedly hitting problems with RBCommons, please contact us!

We’ll post further updates if there’s anything to report.

Read More

Announcing unlimited repositories, PDF document review, and 30-day trials!

We’re very happy to announce some exciting improvements to the plans offered on RBCommons.

 

Unlimited repositories!

We’ve removed the restrictions on the number of repositories your team can set up. You can now add as many repositories s you need without hitting a limit, and at no additional cost. Add all your Git repositories, your forks, open source projects you contribute to, or whatever you like.

This applies to all plans from Starter to Enterprise. If you’re running on the old Micro 2012 or Small 2012 plans, you’ll need to upgrade in order to add unlimited repositories.

 

Upload your PDFs for review

We’ve also introduced support for reviewing PDF documents. Simply drag-and-drop a PDF file into your review request and wait for the PDF to be processed. Reviewers will be able to read through the PDF and comment on any section, just like they can already do with code and images today.

This feature is available on Medium and higher plans. If you’re on a smaller plan, you can upgrade to take advantage of PDF review by changing your plan in your Team Administration page. If you’re interested in trying out PDF review first, contact us and we will temporarily enable it for your team.

 

More time to try RBCommons

For the new teams out there, we’ve increased our trial period from 14 days to 30. This should give you more time to get set up and comfortable with RBCommons.

If you already have a trial subscription, we’ve already gone back and increased your trial to 30 days. You should have received an e-mail from us already. If not, please let us know.

Read More

Welcome to RBCommons 2.0!

It’s here!

We’re so excited to announce the all-new RBCommons 2.0. This is a major update that improves the service in so many ways that we won’t be able to fit it into one post. It’s faster, more reliable, easier to use, and full of polish.

Let’s go over a few of the new features.

 

A super-charged diff viewer

The first thing you’ll see in the new diff viewer is a new file index. At a glance, you’ll see not only what files were changed, but the complexity of the changes. The ring icons beside each file show the proportions of inserted lines, deleted lines, and replaced lines. The thickness of the ring shows how much of the file has been modified.

 

 

In most diff viewers, indentation-only changes look just like any other changes. You have to spend time checking to make sure that the content didn’t actually change along with the indentation.

Not here! Now, indentation-only changes are shown with little markers, which show exactly how many spaces or tabs were used. You won’t have to spend any time looking at whether the text in the line has changed. You’ll know at a glance.

 

 

We’ve also improved the quality of interdiffs (especially when dealing with merges), made moved line detection much smarter, and added an easy-to-use revision selector to quickly jump between diff revisions and interdiffs without reloading the page.

 

The new “New Review Request” page

We’ve completely rewritten the New Review request page, making it simpler to upload your diff and check it for errors. We’ve also gone further and added one-click posting of committed changes for review. Simply select a branch, browse through your commits, and click to post. In seconds, it’ll be up and ready for review.

 

 

Detailed change histories

When you’re working on large changes with several iterations, it’s important to know exactly what changed. We’ve always provided change histories, but they were pretty basic. Now, they’re anything but.

 

 

A slicker dashboard

We cleaned up the dashboard navigation and layout to help you jump between your incoming and outgoing review requests. The sidebar is less cluttered and confusing, and actually useful.

We’ve also addressed two of our most-requested features: Issue counts in the dashboard, and batch closing of review requests.

The Ship It column now shows the number of open issues filed against a review request, if any. These always take precedence over any Ship Its, helping you know at a glance if there’s any feedback you need to address.

 

 

The all-new “Select Rows” column in the dashboard lets you select multiple review requests and close them in one go. It’s very useful when trying to clean up your dashboard if you’ve gotten behind in closing review requests, or if a former teammate leaves. Simply click the pencil in the top-right of the dashboard to add this column, and drag it where you want it.

 

Lots more!

This post is getting pretty long, so we’ll wrap it up. Basically, a lot has changed, and we only touched upon a few of the features. Some others include:

  • Markdown support in all text fields
  • Faster posting of review requests from RBTools
  • Retina icons
  • New support for reviewing different text-based file attachments
  • Reviewers can close issues they filed
  • Easy download of files in the diff viewer

In the coming weeks, we’ll go into more detail on some of the more useful additions in this release, including tips and tricks on how to get the most out of RBCommons 2.0.

This was a pretty major release, so if you have any issues, please contact us immediately so we can resolve them!

Read More

RBCommons 2.0 is coming this weekend!

Updated Saturday, 1:50AM PST: We had some issues with one of the new servers, and had to roll some things back temporarily. This is extending our maintenance window. Hopefully nobody will be too badly affected, but we’ll be down until approximately 5AM PST.

 

We’re making a huge update to RBCommons this weekend. The site will be down for up to 4 hours starting Friday at 11PM PST, as we begin our upgrade to the all-new RBCommons 2.0.

This new update is based on Review Board 2.0, and brings some major improvements to the dashboard, diff viewer, review request change histories, performance, and more. A few of the new features you can expect include:

  • Fewer full-page reloads
  • Faster load times
  • Better, more accurate interdiffs
  • Markdown input for all text fields
  • Indentation markers in diffs
  • Smarter moved line detection in diffs
  • A nicer dashboard, which better displays when changes are approved, or if they have pending issues still open
  • Bulk-closing of review requests through the dashboard
  • Easy posting of existing commits on your GitHub or Subversion repositories, right from the New Review Request page
  • Faster posting of changes using RBTools
  • Better display of exactly what changed in updates to review requests
  • High-DPI icons for those on Retina or equivalent displays
  • Review of text-based file attachments

That’s just a few of the features that this release will bring. We’ll go into more detail after everything’s deployed.

On top of this, we’re moving onto much faster servers, which should help with some of the growth spurts we’ve been hitting lately.

So wrap up your work before this Friday at 11PM PST (Saturday, 6AM UTC). We’ll be shutting down the servers for up to 4 hours as we move to the new servers and begin the upgrade. It shouldn’t take the full 4 hours, but we want to allow for any issues that come up.

Read More

This weekend’s upcoming server maintenance

This weekend, we’re beginning a series of upgrades to our infrastructure that should resolve some stability issues we’ve periodically hit with our database server on AWS. It should also help to improve performance across the site.

This work will start Sunday, August 17th at 6AM UTC (that’s Saturday at 11PM PST for those in California). We’re blocking off two hours for the work, at which point the site will be down. It shouldn’t take nearly that long, though.

Going forward, we’re gearing up for a big update to RBCommons. Along with this, we’re planning some further hardware upgrades that should do a lot to further improve performance. We’re planning this for some time in the next two weeks. We’ll announce the details when we’re closer.

If you are worried that your team is going to be horribly impacted by this maintenance window, please let us know!

Updated Sunday, 12:33AM PST: Maintenance is complete, and we’re back up and running!

Read More

RBCommons 2.0 Beta!

A few months back, we finished up the release of Review Board 2.0, a major release offering features such as Markdown text editing, an improved diff viewer, easy posting of existing commits for review, open issue integration in the dashboard, and more.

We’ve been working to update RBCommons for the Review Board 2.0 codebase, and are happy to announce that the first public beta is ready! We’re trying to squash any remaining bugs, so please play around with it and report back to us.

A few important notes:

  • Your review requests and reviews will not sync between the beta server and rbcommons.com. Don’t use it for production work. Your data will be lost when we switch over.
  • The database is from August 4th. Your review requests and reviews made since then will not be there. This is normal!
  • DO NOT make any changes to your billing or cancel your team or user account on the beta! This will affect your main RBCommons account.
  • If you signed up in the past week and your team or user account is not available on the demo server, contact us, and we’ll get you set up.

With that in mind, give it a try at beta.rbcommons.com! Please send us any feedback you have.

We’re planning to switch over by the end of August. We’ll give a heads-up before we go live.

Read More

RBCommons and the Heartbleed SSL Vulnerability

On April 7th, the world became aware of a critical vulnerability in the versions of OpenSSL powering much of the Internet. These were very serious problems that could allow attackers to gain access to certain confidential data on the server. This vulnerability is known as Heartbleed.

The vulnerability was, fortunately, found by security researchers, and companies like Red Hat and Amazon were quick to put out patched builds.

We take security very seriously, and rushed to update and replace our SSL certificates, ensuring our users would be safe in the off chance that anybody had decided to target us. We are not aware of any attempts on RBCommons, and want to keep it that way.

Even though we don’t believe anyone has targeted RBCommons, we still have a couple recommendations for you.

  1. Reset your password, just to be safe. It might be a good time to evaluate whether you’re using a strong enough password, as well.
  2. Turn on two-factor authentication. This will help keep your account secure, requiring a token code sent to your mobile phone in order to log in.

If you have any questions or concerns, please contact us.

Read More