CodeFlow's workflow was nice, but everything else about it was _awful_. Capturing iterations, comments, threads, etc was the good stuff. The UI - eye-bleeding and amateurish. Network operations - terrible.
Despite all that, the workflow was so good that I'd take it over github CRs in a heartbeat.
As a contributor to a F/OSS project with some serious infrastructure (KDE), Github's uncontested success feels weird. It's a really anemic "solution" to the collaboration problem, especially with projects using it as their only collaboration platform. Most larger ones at least run mailing lists and a wiki or so. Some have a more sophisticated bugtracker, but most seem to stick with Github's... placeholder for one. Probably due to its integration with code review.
>Despite all that, the workflow was so good that I'd take it over github CRs in a heartbeat.
I have to agree, here, wholeheartedly. Put a bug in that would break the build? No worries, as soon as you kicked-off a CodeFlow, it would start a prod and smoke-test build for you. Everyone could also see those breaks and block the review from completing, until you fixed them in a new iteration.
You would think that, with everyone moving (or having moved) from Source Depot to VSO/Git, CodeFlow would've falled into the deprecated products pile but because it was such a worthwhile utility, teams for entire products carried it forward, rather than relying on GitHub's CRs[1].
[1] - It became more of an amalgamation between the two [Source Depot and Git-basd-VSO] but CodeFlow was your one-stop shop to view it all.
I'm sure I'm not the only person who wishes VS Code had capability like this (which isn't to say everyone needs it or wants it, just that when it's needed and wanted it sounds amazing)
The extension is open source and the extension points it uses are all relatively well documented. I'm almost surprised there aren't more extensions doing similar things. (I don't believe that even the Azure Repos extension currently supports an inline PR experience like this.)
Good article. I liked the analysis of how code reviews are performed at Microsoft (yes, computer science is a science!).
My team is fairly happy with github enterprise and the PR workflow but some things about CodeFlow sound better: being able to comment on a single character in a line or share comments between disparate code; and, having a local (non-web) client that runs faster.
Since this thing is coming from Microsoft, I really doubt the tool or the whole process can work outside of Microsoft. It's likely very much tailored to Microsoft needs and full of idiosyncrasies of the Microsoft development workflow.
Here's an example of how things usually are at MS. I worked at MS awhile ago. At that time Git was just being developed, and MS used it's own VCS based on Perforce (which is pretty good, I should say for a centralized VCS). Code reviews were done over email. Kind of like Linux kernel development. If you wanted somebody to review your code, you used a tool to pack your changes into a *.cmd file which contained a diff itself and a Perl (!) script to unpack and view the diff. Then you sent this file to a reviewer over email, and he just ran it on his machine to see the changes you had done. This tool was simple, limited in features, and brilliant. It was hacked by somebody on the Windows NT team back in the 90s. Even if you couldn't unpack a diff into your repository checkout, you could still open the pack as a text file and review the changes, or manually apply them, since it was just a freaking text file.
Come the time MS decided to migrate everything to .NET. Some team at MS similar to TSE responsible for development tools decided that the old Perl tool was inadequate. You don't need no stinking Perl scripts! They developed a replacement in C#. Full of features you can't live without and maybe even an integration with the dev environment (I don't remember). The new tool was distributed in the binary form. The code changes for review were packed into a binary format with plenty of metadata in addition to the actual diff. The problem? Only this tool knew how to unpack this binary format. It worked most of the time and when it worked it was great. But when it didn't work, you were screwed. If it couldn't unpack your code change for any reason, it would throw some C# exception. You couldn't fix the exception and rebuild the tool (you didn't have access to the tool source code or knew how to build it). You couldn't extract the change yourself, since it was packed in a binary format only the tool could extract. You pretty much lost your change if you didn't store it elsewhere.
And this is generally how things were (and still are?) done at MS. They have teams of project managers analyzing and spec'ing out every bit of the development process. Then they create extensive tools to support it with elaborate UIs and automation of everything they can think of. But if you need to do something just a little bit differently, you're left out in the cold because those tools are too close and too brittle to adapt to your specific needs.
It sounds like the DevOps winds have shifted in the last few years at Microsoft. Even Windows (!) is now in git and properly dogfooding Azure DevOps (Boards, Repos, et al), according to blog posts and BUILD talks.
What y'all really want is Google Critique. You just don't know it yet, because you haven't experienced it, as it's internal to Google. The closest public product that I could find is http://reviewable.io (no affiliation) which, while it looks weird/amateurish, nails most of the points which make Critique so amazing. There's also Gerritt, but it's too invasive in terms of workflow, whereas Reviewable integrates with GitHub in a more lightweight fashion.
I have worked in both Google and Microsoft and even though I see how people can be efficient in Critique, I must say I prefer CodeFlow.
In CodeFlow any comment is a floating object with a line connecting it to whatever selection it was created for and you can move it around as you like. You also can easily filter out visible comments by state, author, participation in them.. Features around comparing iterations, marking already reviewed files and similar are the same as far as I remember.
Another reason for my opinion might also be that CodeFlow is probably better optimized for large screens, but this might be caused by the weird Google standard of 80 column limit for source code which I will just never understand in the 21st century where everyone has 24" and up full HD to 4k screens.
I am comparing state of both from 2015 where I worked with both in the same year.
[+] [-] pianoben|7 years ago|reply
CodeFlow's workflow was nice, but everything else about it was _awful_. Capturing iterations, comments, threads, etc was the good stuff. The UI - eye-bleeding and amateurish. Network operations - terrible.
Despite all that, the workflow was so good that I'd take it over github CRs in a heartbeat.
[+] [-] ahartmetz|7 years ago|reply
[+] [-] renholder|7 years ago|reply
I have to agree, here, wholeheartedly. Put a bug in that would break the build? No worries, as soon as you kicked-off a CodeFlow, it would start a prod and smoke-test build for you. Everyone could also see those breaks and block the review from completing, until you fixed them in a new iteration.
You would think that, with everyone moving (or having moved) from Source Depot to VSO/Git, CodeFlow would've falled into the deprecated products pile but because it was such a worthwhile utility, teams for entire products carried it forward, rather than relying on GitHub's CRs[1].
[1] - It became more of an amalgamation between the two [Source Depot and Git-basd-VSO] but CodeFlow was your one-stop shop to view it all.
[+] [-] eyjafjallajokul|7 years ago|reply
[+] [-] dqpb|7 years ago|reply
[+] [-] Game_Ender|7 years ago|reply
- Easy to see the changes an author makes over time to a review
- Integrates with the Package and Ownership system to automatically assign reviewers
- Easy work on changes that touch many files
- Inline lint and code coverage results
- Built in display of unit test and CI results and overall coverage %
- Draft mode to delay review until tests & lint are clean
- Comments move properly as you make changes
- Easy to mark comments as done and find outstanding ones
- Comment on multiple lines instead of a single one
Things that are missing:
- No ability to comment on single characters
- Cannot mark certain files as important
- No way to explicitly mark a change as "simple" (like a rename)
- No web UI to make quick fixes (compared to GitHub is what is most missed)
[+] [-] yodon|7 years ago|reply
[+] [-] humanrebar|7 years ago|reply
Theoretically if there were a standard for managing all that data within the git source graph, you could implement this solely as a VS Code plugin.
[+] [-] WorldMaker|7 years ago|reply
https://marketplace.visualstudio.com/items?itemName=GitHub.v...
The extension is open source and the extension points it uses are all relatively well documented. I'm almost surprised there aren't more extensions doing similar things. (I don't believe that even the Azure Repos extension currently supports an inline PR experience like this.)
[+] [-] mark_l_watson|7 years ago|reply
My team is fairly happy with github enterprise and the PR workflow but some things about CodeFlow sound better: being able to comment on a single character in a line or share comments between disparate code; and, having a local (non-web) client that runs faster.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] alexeiz|7 years ago|reply
Here's an example of how things usually are at MS. I worked at MS awhile ago. At that time Git was just being developed, and MS used it's own VCS based on Perforce (which is pretty good, I should say for a centralized VCS). Code reviews were done over email. Kind of like Linux kernel development. If you wanted somebody to review your code, you used a tool to pack your changes into a *.cmd file which contained a diff itself and a Perl (!) script to unpack and view the diff. Then you sent this file to a reviewer over email, and he just ran it on his machine to see the changes you had done. This tool was simple, limited in features, and brilliant. It was hacked by somebody on the Windows NT team back in the 90s. Even if you couldn't unpack a diff into your repository checkout, you could still open the pack as a text file and review the changes, or manually apply them, since it was just a freaking text file.
Come the time MS decided to migrate everything to .NET. Some team at MS similar to TSE responsible for development tools decided that the old Perl tool was inadequate. You don't need no stinking Perl scripts! They developed a replacement in C#. Full of features you can't live without and maybe even an integration with the dev environment (I don't remember). The new tool was distributed in the binary form. The code changes for review were packed into a binary format with plenty of metadata in addition to the actual diff. The problem? Only this tool knew how to unpack this binary format. It worked most of the time and when it worked it was great. But when it didn't work, you were screwed. If it couldn't unpack your code change for any reason, it would throw some C# exception. You couldn't fix the exception and rebuild the tool (you didn't have access to the tool source code or knew how to build it). You couldn't extract the change yourself, since it was packed in a binary format only the tool could extract. You pretty much lost your change if you didn't store it elsewhere.
And this is generally how things were (and still are?) done at MS. They have teams of project managers analyzing and spec'ing out every bit of the development process. Then they create extensive tools to support it with elaborate UIs and automation of everything they can think of. But if you need to do something just a little bit differently, you're left out in the cold because those tools are too close and too brittle to adapt to your specific needs.
[+] [-] WorldMaker|7 years ago|reply
It sounds like the DevOps winds have shifted in the last few years at Microsoft. Even Windows (!) is now in git and properly dogfooding Azure DevOps (Boards, Repos, et al), according to blog posts and BUILD talks.
[+] [-] m0zg|7 years ago|reply
[+] [-] premun|7 years ago|reply
In CodeFlow any comment is a floating object with a line connecting it to whatever selection it was created for and you can move it around as you like. You also can easily filter out visible comments by state, author, participation in them.. Features around comparing iterations, marking already reviewed files and similar are the same as far as I remember.
Another reason for my opinion might also be that CodeFlow is probably better optimized for large screens, but this might be caused by the weird Google standard of 80 column limit for source code which I will just never understand in the 21st century where everyone has 24" and up full HD to 4k screens.
I am comparing state of both from 2015 where I worked with both in the same year.
[+] [-] piotrkaminski|7 years ago|reply
[+] [-] kartayyar|7 years ago|reply
Amazing tool. Great integration with version control, code search, continuous integration.
[+] [-] akhilcacharya|7 years ago|reply
[+] [-] PretzelPirate|7 years ago|reply
[+] [-] kerng|7 years ago|reply
[+] [-] xorgar831|7 years ago|reply