Am I alone in not liking this line? I don't see the correlation with code review. I initially thought this site was yet another "prevent drunken code commits" tool, which I'm not at all interested in, and not a code review tool, which I find quite interesting.
Scrolling down the page, I came across:
Codebrag is not about code reviews. Well, not only about that. It's about making your life easier by helping you write better code. And that means not staying late. And an empty office on Friday evenings. Because everything is "done done". Just kill the lights and enjoy your weekend.
This is where I closed the site. I don't think about code review as a tool to relieve me of work duties on a Friday night, I view it as a tool to help my software development. To be honest, as someone who works at a small company trying to become a big company, there has never been a moment where everything is "done done".
Just to clarify, I'm not dissing the site overall, it might be awesome, I just think the text on the homepage could be modified to tell potential users such as myself why I should be using Codebrag instead of Github for code review.
Yeah and most of my "late Fridays" have nothing to do with code quality and more to do with idiots from other departments who realize at 6pm they didnkt do anything all week and then stopping by to ask for something so they an say they did it in the Monday AM meeting...
Well, we see code review as a part of ensuring our code quality and squashing potential bugs process. This has quite strong correlation with "emergency production fixes" etc.
Regarding Codebrag vs Github: not all companies are ok with sharing their code with GH, that's why Codebrag is self-hosted tool, you download it and install within your own, secure environment
Given that you're in part competing directly with the free, built-in review tools in Github and Bitbucket, you need to specifically show what you're offering that they aren't.
I'd say that our two main differentiators are:
* a clear "to do" list: you know at first glance if there are some commits to review, and the review process is made as simple as possible, not to get in the way of the development process
* code likes - let the author know that some code is good, you like the design etc. Helps to make the reviews less negative, and in the future can be a great knowledge base!
So $25/mo per 5 users to 'like' a line of code, and the hassle of having another website or pice of software to use on top of my normal issue and source management tools. Not really worth it at all when I can just IM the dev and say 'good job, you didn't break the world haha'.
I would say the the biggest value of CodeBrag is that it is a well designed tool that does one thing well; such tools are usually worth their price - at least for the time they save not fighting other tools. Or writing on IM :)
Besides, how often do you say to others that you liked their code? The simpler that is, the more often people will do it.
I've never found myself wanting a like button for code. It's a nice gimmick, but I don't see it providing enough value that would impact my decision to use a product providing it.
It's not all about this "Like" button. There are other things in Codebrag we think can make it worth trying: all your duties in one place (commits waiting for your review, comments and likes from other users you may want to reply to). Also it doesn't stand on your way, no tons of clicking, going through complicated lifecycles and so on.
The to-do list also applies to followups - reactions to your code. You get a clear list of what comments other people had on your code, and if you don't want to work on them right away, there's no risk they are going to get buried in a pile of email.
Not all organisations would feel comfortable hosting their code on GitHub. I can see large companies or those with sensitive code preferring to keep their source code in-house
I kinda see the gamification point. That's pretty ... okay, I suppose. I do like how you can 'like' a given line. Might be even better if you could like a block/set of lines/function/etc. That little heart to the left is about the only thing I see about it that sets it apart from traditional pull-request-as-code-review.
Unfortunately, codebrag is single-branch only, and triggers reviews on commit. That's a little ... weird. That's how a team I was on did code reviews about seven years ago. But we were also using SVN at the time.
SOP these days is issue a pull request, the PR gets reviewed and when it passes muster is merged. I don't know anyone who does per-commit code reviews.
I guess you could set it up to track commits on your stable branch, and when merge commits come through from topic branches you can review then. But that seems a bit backward.
From the comment replies it sounded like it can only be on a single branch at a time unless you want to restart the app every time you switched branches. Does each developer run their own instance?
I'd assumed all of that post and the comments were about version 2.0, considering it was linked to from the 2.0 documentation "getting started," you can understand my confusion.
The FAQ only says it supports branches (not a word about multiple branches, unlike previous blog articles that took me a while to dig out) -- it makes it seem like 'sure, you can set up code reviews on a branch!'
The link to the blog from the docs page points to nowhere. I just found it by going back to the beginning.
I was also trying to find version deltas (e.g., what's new about version 2.0 from 1.x?), and I guess some 20 second youtube videos count but... if the code reviews are there, shouldn't there be documentation, too?
I haven't used the product; it looks kind of interesting... if extraordinarily light on the details. It gives me no incentive whatsoever to try it out - the only differentiating factor it has between the github pull request review cycle is the per-commit review (I still can't quite git over this) and the ability to heart a line.
If you have [wip] tags for larger e.g., refactors, how do you keep your single branch in a releasable state for production hotfixes? Does every commit kick off a regression test in jenkins? If a [wip] breaks your tests but leaves it in a releasable state, how do you know? If you did know and you needed to get a hotfix out ASAP for something else, do you revert the commit, or do you rebase to a known-stable tag? That just seems ... dangerous.
It doesn't seem like the most workable flow for a continuously live project. It might work fine for products that you can release a stable version of every couple of months.
"Because every commit gets reviewed" doesn't quite cut it for large codebases, even with small teams. Code reviews don't catch everything.
Word. You're welcome - it looks like an interesting idea for a tool, I just don't have a use for it at the moment :) I'll keep an eye on it. My curiosity is definitely there, if the gamification bit gets fleshed out more (and if you weren't so adamant about no PR reviews ;) ).
I wouldn't say these two are in opposition; while CodeBrag doesn't have support for pull request, I don't see why it shouldn't in the future.
It would be perfectly valid to use CB to review commits in the branch for which the PR is done, and then come back to it once more commits (with fixes) are added.
Also, using PR is only one style of work, and I don't think it's the "only right choice". Code reviews of code as it is written, that is during development of a feature, can help you to spot any problems faster. Waiting until a PR is done can result in a long feedback cycle.
You can use CB to track a specific branch that either your colleague is working on, or maybe you are working together.
Yeah, didn't see anything to make me want to change over from Crucible either. If they are going to write a tool that's been written many times already, maybe they should make it clearer what their difference is.
Mhh, you can use it with BitBucket code.. but BitBucket provides already a nice UI for the code reviews with Pull Requests (same with GitHub?). What's the point of using CodeBrag, only the "likes"?
I've always wondered, do people actually like inline diffs? I personally think they're rubbish compared to side-by-side and I've always wondered if I'm a freak as the inline seems to have become popular again with github.
I could go either way. I've used both where I work, and I haven't found that one works particularly better than the other. In most cases, inline is sufficient, you can get the gist of a change (especially a one line change) just looking at them inline instead of a full side by side window. In the case of a real big, messy, merge-y diff, you're gonna have a rough time with either style.
Inline diffs are good for small changes here and there throughout a file. They are pretty worthless for large changes to a file (eg. heavy refactoring).
Bitbucket (and probably Github, too?) uses inline by default on pull requests but has a button to show a side-by-side and another to see the actual file.
We use Gerrit at work, and having tried numerous tools in the past, we've settled on Gerrit because it's efficient with our time and is focused on doing CRs well. Things that I enjoy:
* Keyboard shortcuts.
* Inline or side-by-side comparisons
* Patchsets from changes
* Makes it easy to check the change locally
* Easy inbox/dashboard for CRs
* Provides structure to passing code reviews (not everyone should be able to +2 a CR)
* It actually has an interface that is useful
We have tried Crucible a couple of times, and it just didn't fit our style of work and process.
Asking for a review and doing reviews in Crucible is a multi-step workflow. Also, there is no clear list of what's already reviewed and what's left for review. Overall the tool seems "heavy".
I'm sure Crucible works great in some teams. CodeBrag is designed more for smaller teams, which want to have tools be as simple as possible (while maintaining functionality, of course), and like a simple, streamlined process.
Codebrag is a lightweight, simple to use tool, while Crucible is more feature-packed.
For example in Crucible you need to create reviews (select commits and assign a developer who will review them), in Codebrag commits to review simply appear on the "To Review" list. It depends on the context which tool is more suitable for your team.
It sounds like this means post-merge code review too? After getting used to a pre-merge code review tool that does hard-gating (gerrit), I have trouble with other tools.
i can't really tell what service is being offered. or maybe i am being naive and missing the point...
i guess work on the page so is clearer.
imo there is a very strong sell and not enough information on the product for me to determine what it does, if i need it and esp. if its worth forking out for.
Am I alone in not liking this line? I don't see the correlation with code review. I initially thought this site was yet another "prevent drunken code commits" tool, which I'm not at all interested in, and not a code review tool, which I find quite interesting.
Scrolling down the page, I came across:
Codebrag is not about code reviews. Well, not only about that. It's about making your life easier by helping you write better code. And that means not staying late. And an empty office on Friday evenings. Because everything is "done done". Just kill the lights and enjoy your weekend.
This is where I closed the site. I don't think about code review as a tool to relieve me of work duties on a Friday night, I view it as a tool to help my software development. To be honest, as someone who works at a small company trying to become a big company, there has never been a moment where everything is "done done".
Just to clarify, I'm not dissing the site overall, it might be awesome, I just think the text on the homepage could be modified to tell potential users such as myself why I should be using Codebrag instead of Github for code review.