Jenkins + SVN + .NET projects + code review. Best way to do that?

Question

What is the best way to integrate .NET Projects with Jenkins and SVN (I don't know if there is any chance to switch to git right now) and be able to review code after build and before production.

I'd like to have something like this:

1. Developer checks out repository.
2. Developer implements something.
3. Developer commits changes to repository A (SVN)
4. Jenkins monitors repository A (SVN)
5. Jenkins starts build.
6. Jenkins starts unit tests.
7. Everything is OK.
8. Jenkins commits changes to repository B. (review repository)
9. QA guys reviews code.
10. QA guys commits changes to repository C (production)

6a. Not everything is OK. 6b. Jenkins sends notification to developer that his commit broke build and we go back to step 2.

I know how to do steps 1-6. More or less. I know I can build everything with MSBuild, so this shouldn't be hard, but I don't know exactly how to configure steps 6-9,

GIT:

I think with git it would be far easier. I saw that there is Git Publisher in post-build actions and I could push changes to branch - "review-branch" or something like that and send notification to reviewers. They will pull repository and everything would be great. hmm also maybe instead of pushing to review branch, Jenkins should create pull request to that branch. But as I said it would be scenario for git. I wrote it here, because for me git is better option here, but maybe not possible. I just want to know if I'm not missing something if we are talking about git.

SVN:

Here I have no idea how to do that. Does Jenkins have something built-in to deal with 'push' to second SVN repository? How can I commit code to repository B?

Review: What is the best approach? - (GIT) Jenkins creates pull request -- if possible - (GIT) Jenkins pushes to second review-branch and sends notification on email or creates some tickets on some issue tracker (Redmine/Jira) - (SVN) Jenkins commits to review repository and sends email or creates tickets. - or maybe it's better to integrate everything with ReviewBoard/Gerrit or something similar. Right now I've never used such software and I read that Gerrit is a bit troublesome.

Answer 1

There's something you need to remember:

In a version control system, everything is reversible

That means you can do a code review on committed code, and fix any issues in a new commit. In fact, this is actually good to do with Subversion because Subversion gives you a nice revision number that contains all the code changes. Everyone is on the same page this way. ("We're reviewing revision 23,340"). Most code reviews are looking for things like forgetting to check for a null pointer, etc. If the code is really bad, Subversion makes it easy to completely reverse the change.

Jenkins will immediately tell you if a build is bad, and our policy is that a developer has 10 minutes to fix the problem, or back out their change. (90% of the time, they back out their change). We have our system setup, so both the developer and Jenkins use the same build mechanism. This allows a developer to test the build and run the unit tests before committing their changes.

This is why most version control systems don't have shelving, and you don't see three sets of repositories and most places. This isn't your apartment. Your mom isn't going to come by and see your code history. It doesn't have to be nice and tidy. Let it reflect what's going on.

Simplify. Remove the last three steps. Do your code reviews and fix the code in the same repository. It means 66% fewer repositories that must be maintained. 66% less hardware. And,

---

All you really need is a way to track your code reviews. You can use something like Crucible, but you can also use Jenkins. There are two ways of using Jenkins for tracking changes:

• Add a description to the individual builds: Simple to do and requires no additional plugins. The description is flexible. You can go into a project, look at a list of all the builds and see the description. Simple and easy.
• The Promoted Build Plugins: There are two of them: One is the standard one, and one is simple.

The Promoted Builds Simple Plugin is ...well... simple. You specify all of the various promotion levels in your Jenkins configuration page, and that's what all the builds will use. Only a single promotion level per individual build is allowed, and it's all manually done.

The standard Promoted Build Plugin is a bit more work, but it's also way more powerful. It allows each Jenkins job to have its own build promotion scheme. Promotions can be both manual and automatic. When a build gets promoted, it can spawn other actions such as sending out email, deploying to a server, etc. Plus, you can show multiple promotions. Imagine the following promotion levels:

• Build is passed Unit Testing: Automatic promotion when a build is done and passes its unit testing. An email could be sent to the QA person responsible for the code review:
• Code Review is complete. No major issues: The build is generally good. Maybe a few minor issues, but this build could be used for deployment to an other environmen for further testing.
• Code Review is complete: Major issues Found: This build had major problems, and should not be considered ready for deployment into another environment for further testing.
• Developers fixed issues found in this build: Build is still bad, but at least you know the developers have claimed to handle the issues in this build.