i work in a SQL Development Environment.
We have three branches namely DEV, TEST and LIVE.
Whenever a developer did something and wants to deploy on Test System i need a mechanism within TFS that enforces him to do a code review.
I know this can be done by enforcing a code review check-in policy.
But I don't want to trigger a code review with every check-in but more whenever somebody merges to TEST branch.
Think of it more as an approval enforcement. I want that TFS is requesting a code reviewe whenever somebody branches into a different branch. The best scenario is that i can specify the branches that trigger this behaviour.
Code Review Check-in policy can specify a path to apply this policy to, so you can only apply this policy to your TEST branch:
By the way, if you use Git team project in TFS 2017 or VSTS, you can enable branch policies to require code reviews for a branch. More information, check: https://www.visualstudio.com/en-us/docs/git/branch-policies
Related
Please read carefully as I believe my use case is unique and I have tried searching a lot on how to do this, but I am still unsure.
Generally, I am trying to set up a repo for a group of developers to work on and have it contain CI checks and require reviewers. However, I have run into some issues with how Github enforces branch protection. On top of that, I cannot use Actions as we are using a self-hosted Enterprise Github through an organization.
My desires:
Use Jenkins (which is already set up and building) builds as checks for PRs. If the checks don't pass, you cannot click merge on the PR.
Allow pushing to a branch that I have a PR up for so the author can push changes based on PR comments.
Require two approvals from maintainers. You cannot click merge without these.
It seems I could protect a master branch for example. However, I would like to enforce the PR checks whenever a person chooses to make a PR. For example, from one dev branch into another dev branch.
Use case:
An author sets up a PR for merging a branch some-work into dev. Jenkins builds the HEAD of the branch some-work to evaluate the checks. I would like to enforce this PR to have two approvals from maintainers. So, those reviewers make some comments and request some changes. The author makes those changes and pushes a new commit to the some-work branch. Jenkins runs on the new HEAD to reevaluate the checks. Then, if-and-only-if the two reviewers approve and the checks pass can the merge button be clicked.
What I have tried:
Using Github branch protections: the required approvals and the required status checks. However, this prevents any pushing or force pushing to the branch being developed on. I could just apply these protections to master, but I also want these checks part of any PR (even dev2->dev1, for example).
Github actions, but these are not available in the self-hosted enterprise Github I have to use.
What I understand:
I understand that I can protect master, for example, in this manner with the native Github branch protection. However, if I want master to be something that always works, it is understandable that developers would break up a feature into multiple branches. They would also want their follow developers to review it when merging it from their branch to an intermediate (non-master) branch. Then the actual branch being merged into master consists of code written by many developers.
Thank you all in advance for your time and help. :)
Using Github branch protections: the required approvals and the required status checks.
However, this prevents any pushing or force pushing to the branch being developed on
But... that issue (not being able to push a protected branch) could be part of a possible solution.
I would make jenkins create/reset a PR branch based on a push on a topic branch (like some-work-pr, based on some-work)
some-work is not protected, and can receive commits at any time
some-work-pr is created by Jenkins protected, and cannot be modified: compilation/test/review/approval happens here.
PR would only be done from xxx-pr branches (protected PR branches created/managed by Jenkins), while other topic branches continue to evolve.
You can only enforce these policies with branch protections, so if you want to enable required CI checks before merging a PR for all branches, then you need to protect all branches (e.g., with the pattern **). In that case, you'll need to have developers use a forking model for your repositories so that they can push code to their forks and then merge in the changes via pull requests only.
Note that if you adopt an approach where projects are implemented as a set of small, incremental changes that are merged frequently and use feature flags to control whether the code is enabled, then as a practical matter developers will only merge into the main branch and you can get away with only protecting the main branch.
I want to be able to review every check-in before the code is applied to the branch, is it possible in TFS?
I know we can add check-in policy to force code-review but this is applied before the check-in and not after.
I'm looking for a way that would not block the existing flow.
Thanks
TFS supports two source control systems that each have their own workflow based on established practices:
TFVC - This is a server based source control system that supports Code Reviews using Shelved changes prior to check-in. As #daniel Mann stated it works exactly as you described.
Git - This is a distributed source control system and uses Pull Requests to facilite reviews of Merges. Since all work is done on a separate branch, you review the proposed pulls of code from one branch to another.
It sounds like you are using TFVC so the existing Code Review model would fit your purpose.
Suppose I have a team project with two branches: "main" and "dev" (fictional names).
As things are now, new code is merged into "main" without any code review. Also, anyone can check-in directly to it. We would like to change that.
I would really like to have something like Git's pull request functionality. I know we can use permissions to keep everyone from making check-ins at the main branch. We can also use permissions to make sure that only a reviewer can merge into the main branch.
But how can we review the difference between both branches before doing a merge?
I found out that the Code Review feature of TFS 2013 only works if you have the Premium edition of Visual Studio. Not all of the devs here have it, and we cannot install other editions for them, nor get VS2015 or later versions.
You can add a custom check in policy for code review before checking in. There is an existing Code Review Checkin Policy can be downloaded from website below, this policy allows you to enforce Code Reviews at checkin time.:
https://visualstudiogallery.msdn.microsoft.com/c476b708-77a8-4065-b9d0-919ab688f078
Is it possible to merge the development branch into the staging branch, when the development branch successfully builds?
Assuming your goal is to have your code deploy to a staging environment then I would suggest that you have the wrong promotion model there. Code promotion models, like you describe above, are pretty antagonistic to continuous anything. Either you just want continuous integration, or you want to go all the way to continuous delivery you are doing it wrong. Switch from code promotion to binary promotion.
You should build a single version of your application, from a single branch, and promote that through various states of quality. Added bonus is any tests run against these binaries are valid passed in any environment. Recompile and you have to reset your test plan.
http://nakedalm.com/create-release-management-pipeline-professional-developers/
It pretty east technically to change to a binary model. Any difficulty will be political and cultural within your organisation. It is however very much a fight worth having.
You could customize your build, so it does this using the tf.exe command-line client (or the TFS API). I would use a powershell script, that in-turn used the tf.exe tool to do a merge + check-in to the desired branch.
However, the problem is this only works if there are no conflicts. If there are conflicts, you won't be able to automatically resolve them in order to complete the merge.
You can configure a build definition to your staging branch in "Gated Checkin mode" trigger.
When you commit code to staging branch a build must be run successfully before you code is uploaded to source control.
You can find more information about "Gated Checkin" in MSDN:
https://msdn.microsoft.com/en-us/library/dd787631.aspx
In the company I work for we have a Release branch from which we publish versions to production.
I want to prevent a situation where someone checks in changes made in that branch directly without the changes were synced from the development branch.
Is there a way where I could set the Release branch to allow check-ins for change-sets which are of "Merge" type only?
By this I could ensure the change-set was originated from the development branch and achieve my goal in addition to preventing non synced code between production and development branches.
You cannot fully restrict a branch to allow merges only. But there is a checkin-policy made by a Microsoft MVP which you can configure. Combined with the checkin-policy from the TFS Power Tools you can configure it to a speficic folder. The configuration process is explained on teh download page.