In JIRA, what is the appropriate procedure to add a Workflow to a Workflow Scheme?
In my case I created a new Issue Type which is referenced by a newly created Workflow. In order to add the Workflow to a Workflow Scheme, the Workflow Scheme must be Inactive. In order for the Workflow Scheme to be Inactive, I have change each Project's Workflow Scheme to something else. Only when there are no Projects using the Workflow Scheme can I edit it.
When changing a Project to a different Workflow Scheme ("Associate Workflow Scheme to Project"), JIRA warns that a backup should be made and that every single issue will be changed. Something tells me this is an overkill for such a simple change. I really don't want to alter every issue just to add a new Workflow to a Workflow Scheme.
Am I missing something?
Follow up: According to Atlassian, there's no choice but to migrate to the new Workflow Scheme.
Go to Admin, Schemes, Workflow Schemes. Copy the Workflow scheme currently in use by your project. Edit the copy and assign the new workflow to the issue type. Then go back to the project and select the new workflow scheme, which may prompt you about migration of issues if necessary.
It's not overkill, it's just being careful. You don't actually change anything unless you have to, for example if there are issues of the new issue type in the project.
~Matt
Related
In our organization we use TFS 2018 and Visual Studio 2017 Enterprise.
As far as I got until now, there is a way "client-side", configuring from Visual Studio, selecting Team\Team Project Settings\Source Control\Check-in Policy\Code Analysis and I should the custom ruleset defined.
I need two things:
Set a custom guideline that is mix of both default Microsoft ones and other tools' guidelines, like Roslynator or StyleCop.
Create a custom policy server side in order to prevent check-in from Visual Studio (or whatever client we can think of) if code is not compliant to those guidelines.
For the first point, I'll make a clear simple example.
There are the guidelines embedded in Visual Studio.
But they are not complete and I would like to extend them, taking stuff here and there or defining new ones from scratch.
I want to use e.g.:
CA1500: Variable names should not match field names (from default Visual Studio Managed Binary Analysis)
RCS1145: Remove redundant 'as' operator (from Roslynator)
RCS1204 Use EventArgs.Empty (from Roslynator)
SA1302: InterfaceNamesMustBeginWithI (from StyleCop)
SA1305: FieldNamesMustNotUseHungarianNotation (from StyleCop)
How can I do it? And can i do it without make me define it at project level (like incorporating stylecop file for every .csprj) but more at least at solution or Team Project level?
For the second point, I already defined the compulsory comment and compulsory work item attached.
And I can even define new policies, it's true, but they can all be overridden client side.
Is it possible to prevent that?
The best solution for this is two part:
Educate your users to configure the right policies and editor settings. Creating custom project templates and distributing those can help (or deploying a custom build target onto the machine which enforces good defaults.. Having a good local policy will help people do the right thing and people who are supported to do the right thing will likely not try to get around that.
Setup a CI build for your projects. VSTS and TFS have a nice feature which will run a build whenever code is changed. You can even set it up as a Gated Checkin build which will check the sources before they're checked in. This check happens on the server and is much harder to by-pass. You can also configure the build to always override the code analysis settings, even if they're not configured in the project. My MsBuild Helper tasks will help you setup the right MsBuild properties to do that.
As to your more specific questions:
You cannot setup Code Analysis Rules at the Team Project level without also configuring the ruleset for all Visual Studio Projects. Otherwise the checkin policy will cause the check-in to fail, but the developer will then still have to update all projects in the solution with the right ruleset.
You cannot prevent people from by-passing the local check-in policy. The best you can do is to use Reporting Services and Alerts to detect the breach of policy and take corrective action.
You could add the Rule Set into TFS source control and then select it from Code Analysis Policy Editor. Check the screenshot below:
Check-in policy is already applied to a team project, not a single project.
To edit check-in policy, you must have the Edit project-level information permission. You could deny this permission for the users to prevent them from editing the check-in policy.
I have created a custom workflow where tickets or issues are submitted then the order of workflow steps is:
review (ALL)
business justificatioN
in progress
verification (ALL)
deployment
testing
done
ON HOLD (ALL)
RETIRED (ALL)
I created the custom workflow by making a copy of the default workflow with TODO IN PROGRESS, and DONE Status however when you go to edit an issue in my custom workflow you still have the option to change the status to TO DO (from the default workflow) even though my custom workflow is clearly the one which is selected for the Scrum project.
What do I need to modify so that the TO DO STATUS from the default workflow isn't showing up at the top of my issues.
For example if an issue is created using the custom workflow the STATUS defaults to REVIEW as expected as it is the first step in the workflow. When trying to transition it to the business justification step while viewing the issue a STATUS of TO DO is visible.
How can I remove the option to change the status to TODO given it is not part of my custom workflow which is applied to the project and is instead part of the default workflow.
Can I remove the default workflow for the project? to achieve this (I am not sure how to completely remove the default workflow) so far I have only been able to assign my own.
This is possible if either:
The TODO status is still used in your custom workflow.
You're looking at an issue that does not use your workflow. This is possible if your "Workflow Scheme" is not configured correctly. A project has a "workflow scheme" that can contain multiple "workflows" for different "issue types". You can review these settings in your project's settings. The documentation is available here.
is there a way to add custom workflow to "Create new project" screen?
http://s13.postimg.org/f1acwcerr/Untitled_1.jpg - create new project screen
Or make my custom workflow to be default, but seems that it's not possible at the moment.
The problem is that I created a workflow that suits my needs better than those which are available by default at marketplace. I would like to use this workflow as default for all projects. Or have an easy way to create a new project based on my custom workflow.
Thanks
There is no way to set a user created workflow as the default but there is a issue opened with Atlassian created about it. (See JRA-9363)
Your only option would be to create the project and then immediately change over its Workflow Scheme to be that of your custom one that has the custom workflow associated to it.
I manage a large TFS 2013 team project, whose code we're now splitting into multiple independent parts, each part becoming a tenant in the team project. Each such part would have its own build definition(s). I want people in each part to be able to create/edit/manage their build definitions, but not others.
Currently, I create the build definitions myself upon request, and then set permissions on the new definitions, and tell people to edit them. I have permissions to that since I'm in the Builders VSO group, and therefore have Edit build definition and Administrator build permissions on the Team project.
However, I'd like to grant everyone the permission to create new build definitions and administer them, but not have permissions to change other permissions. Is this possible in TFS?
Its not currently possible to do that out of the box. However, you could setup a webpage that automated the task that you currently perform and add a new build definition and give permission to the correct team... Then they can manage it from then.
I would recommend using PowerShell for the action and the webpage mearly calls that.
I'm currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).
I wonder what the easiest way is to test the build templates I'm creating?
Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?
I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).
Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.
I want to test my builds against the teams latest code-base without having to branch it over to a trial project.
Instead, I do the following:
Create a separate build definition called 'Infrastructure'
clone a production definition
Set the trigger on the Infrastructure build definition to manual.
Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
keeps the notification of broken builds away from the bulk of the team).
Create a separate build process template, called 'Infrastructure.xaml'.
Point the Infrastructure build definition at the Infrastructure process template.
Now when I want to iterate on a new build feature for the team:
Check out the build process template I want to update, and lock it.
Copy the build process template I want to update overtop of the Infrastructure.xaml.
Add my build feature to the Infrastructure.xaml file, and check that in.
Use the Infrastructure build definition to test my changes.
Iterate over 3-4 until I get it right.
Complete the feature and have my changes verified by another Infrastructure team member.
Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.
This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.
#d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.
Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.