I'm looking to migrate a project from one org to another in Azure DevOps. We've ended up with two or three orgs, and this project that I'm looking to move has all sorts of weird and wonderful work items created and custom fields added. What I'm looking to do is move the project and then see if I can persuade the powers that be that certain things can be dropped but I have an immediate need to move as-is so that reporting and other work isn't impacted.
I have tried to get this to work with the migration tools (and tried to follow the videos) but have hit a dead-end. I think there are two issues potentially. One being the ReflectedWorkItemId. It says that it's not found in User Stories but I'm not sure how to resolve this? Do I go into user stories and add a field called 'ReflectedWorkItemId' and populate it with the work item number and/or add the same field in the destination org process?
It also mentions in the info that it can't find one of the Work Item Types - Processes. There are a few other custom work item types that have been created too but I assume it's given up on the first one. Do I have to create all of the work item types and the custom fields for each work item type in the destination org? Or am I getting the wrong end of the stick with this?
To provide sync as well as migration it is important that the tools knows which items have already been migrated. This is the purpose of the ReflectedWorkItemId field.
The field is not required in either case, however... if you don't have
the field then the system cant be re-run as it will re-copy all
completed work items. If you add the field to the target then it will
only copy those items it cant find. If you add the field to the source
(yes it needs to be the same refname), and set UpdateSoureReflectedId
to true then you can also filter the source, using a query and limit
what you load.
The former prevents duplicates, and the latter allows you to filter
the data load...
This is mentioned in this document. Here is a similar issue you can refer to.
TF201077 that usually happens when the target Project does not have a work item of that name. You can refer to this issue on github for help.
Related
I can start typing "#per" in a Devops task description/comment and it brings up suggestions. However it only shows a subset of all the stories which means the one I want is rarely listed and I have to go look it up.
For instance I have two work items (on the same epic) called "perform analysis" and "determine permutations" but typing "#per" only shows the second one.
Is there some logic used in the searching based on item fields that could be to blame i.e. it's a feature rather than just not working well?
Normally, when using the #mentioned to link work items, the expected syntax is #{ID} instead of #{Keyword}.
If using the syntax #{Keyword}, it may be not able to return the expected result. So, it is recommended using the #{ID} as possible to search and link work items.
For more information, you can reference "Link work items".
[UPDATE]
When you use #{ID} to search and link a work item, normally it will prioritize the work items that you've recently modified or are assigned to you.
Good day all,
I am trying to build a custom work item type in azure dev ops. i really like the functionality of the test case steps feature. Its a table, with simple navigation and CRUD operations. However, when you go to inspect how test cases builds this feature, all it says is "Textbox (multiple lines)". Which isn't the case.
Does anyone know if it is possible, or if there is an extension to add tables as a field to a work item type?
If you want to customize a work item field like the "steps" field of the test case , I am afraid this demand is not feasible. I also tried to add a field by using an existing field (Steps),but this not works,the actual field still displays like text.
The Steps field is used to support Test case management. So I think this field is specific to the test case. For details ,you can refer to this docs.
You could also submit a suggestion ticket to suggest the new feature through this url.
I've had a number of problems using the provided Kentico Import Toolkit, namely when using the "Import new and overwrite existing pages" option to update my existing/already imported pages. I'm using a custom SQL query to import and have had a profile saved for each import I've needed (client has article based site so a few tables of similar information) to try and keep each as consistent as possible between imports.
Here's the problems I've encountered thus far (in no particular order):
the tool tries to guess which fields from the query correlates to the fields of the page type in Kentico for you, which is a nice idea, but seems poorly implemented. If I'm not very careful and reload the profiles every time I import I've had instances where fields changed inexplicably when testing imports because the tool thought it knew which field I wanted
this is more the problem when importing/reimporting multiple times in a session and choosing to go back and load the same profile (without reloading)
the NodeAlias field is only seemingly required on update/reimport rather than on initial import. I'm sure there's an internal cleaning of the document's title to generate a NodeAlias and this is generated fine when importing documents while NOT providing the NodeAlias. After importing the items initially and wishing to update however the NodeAlias is seemingly required as you'll get errors with text asking it be included. This implies to me that there's matching of the NodeAlias along with the given ID field, which should be fine in theory but isn't specifically mentioned anywhere in the tool as best I can tell.
I've had instances where reimporting items will change/strip their NodeAliasPath. I've gotten around this by specifically setting the NodeAliasPath (which only shows after selecting "Show Advanced Columns") but like NodeAlias path before it, I'd think the tool should be smart enough to know to keep the path if not specifically given for updated items.
it seems very odd that in order to match on ID for previous items you have to provide the name of the new column instead of the old one. My example: client was using just a field named 'id' and the new one is 'OriginalID' to clearly differentiate it from the Kentico derived ID fields. To match the items I have to use 'OriginalID' rather than 'id'
A couple of notes/niceties or potential updates along with the above:
it would be nice if there were some way to select if the page should
be published or not through a single query. Currently having the
"Automatically publish pages under workflow" toggle checked seems to always publish
the items. I have an instance where the client has old documents in
the provided DB dump that they don't want visible on the site but
want preserved in the DB if they change their mind later. Currently I
have to perform 2 imports, 1 for the unpublished and a second for the
published items, to accommodate this, which is quite cumbersome
I'll likely edit/add to this as I get responses. This isn't really a specific problem (as I managed a workaround to the NodeAliasPath stripping problem, which inspired this post initially) but more just me asking if these are bugs,if I'm not using the software as intended, etc.
You've stated all the problems you're having/experiencing and possibilities why they are happening but didn't ask a particular question. If you suspect they are bugs, then I'd go to directly to Kentico Support and report the issues there since these are things that have been part of the KIT for as long as I have worked with it.
I work in IBM RTC (Rational Team Concert); the Project Area I own is built on the IBM Formal Project Management Process Template.
I’m looking for a mean to get work items created programmatically;
I do want when I create a Change Request work item, to allow the selection of different teams and from this attribute(s), create automatically children work items Task directly assigned to the right team/member.
How would you recommend to do so?
Although it is not a direct answer to your issue, but I guess it would help. It's more like a workaround more than a solution to your requirement.
The work around is divided into two steps:
Create a work item template from a CR with all its sub tasks included in the work item template.
Create a CR using the previously created template programmatically.
Note: This means that you'll need to create a work item template for each team.
I do all development in a single application. when a new version is ready I create a template and give it a version number. this way I can store a history of all previous versions.
the development templates are used to push the new design to many applications via replace design.
Creating manual version number or template names is fine but I am looking for a more automatic way of finding out which build the different applications are inherited from
When I visit the different applications I would like to be able to see which build number each application are inherited from. is this possible?
A simple build time stamp could do, but is there a built in build number that can be used and that can be displayed on the xpage.
e.g Build 2012092712345
Update:
Thank you for all your answers, many good suggestions but it looks like all require manual work.
The best solution would be if there is a way to read (from ssjs) a timestamp from any file within the nsf that is always updated during a build. is this possible?
In classic notes, there was a method to add a shared field with a special name to the application. Cannot remember the details, but have it somewhere on the disk.
Then you can see the build number in the design tab of the application properties. And you can of course display the value in your applikation as well.
But you have to fill the item manually on each build. Or use teamstudio Buildmanager. This tool adds the value automatically.
And I also guess that you can write some code that changes the value whenever you create a new build.
Another option would be to use a versioning system like CVS/SVN. This is possible since 8.5.3.
Source control
I think I know what you are meaning. Your a pushing out design and want to check thru code what version each database has. I usually do this with a Build form. In this form I have computed fields with all the data I want to retrieve. Then I open the database with an agent create a document
and set the form field to "BuildForm" and do a computewithform.
Now I can see all information about this database.
I once wrote a rudimentary build system for "classic" Notes, and had the last part of the build pipeline create a form named _BUILDID_, and put the build id in the $Comment field.
The main reason to create a form instead of a shared field was that I could dynamically fetch the form using NotesDatabase.Forms, and open up the desired field.
I sure hope there are simpler solutions nowadays... :-)