New Relic CodeStream's feedback requests are powerful enough to use for traditional end-of-cycle code reviews, but at the same time they're so easy and flexible that you can use them throughout the development process to get quick feedback on work-in-progress. You can even use feedback requests for uncommitted your changes.
Traditional code review happens at the end of the development cycle, when you’re looking to get the changes merged. Not only are end-of-cycle code reviews much more burdensome on your teammates, but you run the risk of identifying issues so late in the game that you end up having to decide between blowing up your schedule or taking on technical debt.
Whether you’re at the beginning of a project, with just some stubbed out functions, are mid-way through a work in progress, or are ready for a final review of a finished project, CodeStream enables feedback at any point during the development cycle. CodeStream handles the complexity of sharing your current status, including pushed commits, local commits, and staged and saved changes. Your teammates can provide feedback from their IDE, with no need to switch applications, and no need to switch branches or pull changes.
By the time you get to the formal code review/pull request at the end of the development cycle, it’s far less painful and more of a formality because issues have been raised, discussed, and resolved all along the way.
To request feedback at any time, regardless of the current state of your work, click the + Create button at the top of the CodeStream pane, or the + Request Feedback button in the header of the Feedback Requests section. You can also use a keyboard shortcut (
r on a Mac).
With a single click you can name the feedback request based on the last commit message, the branch name, or, if you started work by selecting a ticket, the ticket title. CodeStream assumes that you are requesting feedback on changes in the repository/branch of the file you've currently selected in your editor. If you have multiple repositories open in your IDE, you can change this via the repository dropdown at the very top of the feedback request form.
Depending on your organization's settings, CodeStream may suggest specific reviewers. Based on the commit history of the code being changed, the suggestions may even include someone that isn't yet on your CodeStream team. In that case, they'd be notified by email. Hover over a reviewer’s name to see more details or to remove them. If multiple reviewers are assigned you may also have the option to determine whether any of them can approve the review or if each one has to approve it individually.
The Changed Files section lists all of the files that have been added, removed, or modified. Click any file to view a diff if you want to review your changes before submitting the feedback request.
If you have a file that’s not suitable for review, such as a checked-in binary file, you can hover over any file and click the x to exclude that file from the feedback request. That file will be moved to a list below the form. New files are, by default, excluded from the feedback request, but you can hover over their entry in the list and click + to add them.
Hover over an excluded file and click the trashcan to permanently exclude it from all future feedback requests. Permanently excluding files creates a
.codestreamignore file in the repository. If you think your teammates will also want to exclude these files (for example, a
package-lock.json or other system-generated file), you can commit and push the file so that they can make use of it as well.
The changes represented across the selected files are broken out into four different categories, allowing you to select exactly what you would like to include in the feedback request. This includes changes that haven't been pushed, or even committed.
The four categories are:
- Saved changes
- Staged changes
- Local commits
- Pushed commits
Commits are listed in descending order across the Local Commits and Pushed Commits sections. If you uncheck the box for a commit, it will automatically uncheck the boxes for all of its preceding commits. In other words, the commits included in the feedback request must be consecutive. Only your commits are checked by default, but you can include any of them in your review.
Make sure the email address in your git configuration matches your CodeStream email address. Or set up a blame map to map your git email address to you CodeStream email address.
Optionally, you can share your feedback request out to either Slack or Microsoft Teams.
When you submit your feedback request, your teammates will be notified via the activity feed, with anyone assigned as a reviewer being @mentioned so that they’ll also receive an email notification.
The best part of CodeStream's feedback requests is that having your teammates look over your code doesn't put any extra burden on them. There's no need for them to set aside their own work to switch branches or pull changes and no need to for them to leave their IDE. As long as they have the appropriate repository, they can open the feedback request and start reviewing your changes.
Click any file in the Changed Files section to review the changes. The changes are presented with a diff in your editor. You can step through the changes in the file using your IDE's native navigation or click the up/down arrows at the top of your IDE. For JetBrains IDEs, CodeStream only supports the side-by-side diff viewer.
Typically, the diff will represent the changes in the branch associated with the feedback request (such as, a feature/topic branch) against the base branch, at the point at which the feature branch was created. With CodeStream diffs this may not always be the case, because the developer may not have included all of their changes in the feedback request. As a result, the version of the files that the changes are being diff’ed against may, in fact, also include changes that aren’t in the base branch. This is important in order to provide continuity.
If you have a general comment about the changes, add a reply to the feedback request's thread.
If you want to comment on the actual changes, select some code from the right side of the diff and then click the comment button that appears in the CodeStream pane next to your selection. You can also use a keyboard shortcut (
c on a Mac) after selecting some code.
Since you have the full file context, you aren’t limited to commenting on just the lines of code that were changed. For example, you might notice another part of the file that needs work as well or that you simply want to reference.
Whether it’s a general comment or a comment on code, you can mark it as a change request to let the developer know that it’s required before you’ll approve the changes.
While you're providing feedback, you can even comment on files that aren't part of the changeset and they'll get added as a reply to the review. This is helpful to be able to point your teammate to another location in the codebase that might need improving.
All of the change requests associated with the the feedback request are summarized in a section at the top, in addition to being part of the discussion thread. This is where they'll get marked complete when the work is done.
Look for the green and red buttons at the top to either approve the changes or request additional changes. If there are any open change requests, the approve button will be replaced by a blue button that shows the number. You can still approve the changes, but we wanted to make sure you were aware of the outstanding work.
![A screenshot showing outstanding changes](/images/ApproveWithChgReqs3.png "Outstanding changes)
When there are multiple reviewers, and an approval is required from each, CodeStream makes it very clear when there are still outstanding approvals. The blue button at the top right shows how many approvals are outstanding. The green thumbs up on the headshots of reviewers indicates that they've already approved your changes.
A typical workflow involves the reviewer leaving some comments or suggesting some changes and then the developer responding to that feedback with more changes to the code. To continue the process, click the blue Amend button to add your changes.
Similar to when you originally submitted the feedback request, you can choose from your saved and staged changes and your local and pushed commits. Any open change requests are also listed so you can mark off any that are addressed by your update.
By default, when the reviewer goes back into the feedback request, they’ll be looking at the complete changeset (such as, changes across all updates) as they go through the diffs for each file. They can also view the diffs for any individual update.
The feedback review process can continue across as many updates as needed to get to the final approval of your changes. Once the feedback request has been approved, you can create a pull request from within CodeStream to get your code merged.
The feedback request can't be amended or reopened once a pull request has been created.