I'm having problem with deploying changes to Sitecore item. I've made changes in the template item in Sitecore. All changes of Sitecore items are stored in TDS. During the build TDS generates an update package, then I install this package using Sitecore UpdateInstallationWizard during deployment.
The problem is that I've already deployed several builds, and just found out that changes are not applied to this template item: I've removed one field from the item, but it still appears, also I've changed another field value in the _Standard Values but it does not change after deployment.
Could you please help me to find the cause of this issue? Is there any way to review what items are in the package?
UPD: I've renamed package into zip and was able to find the template item itself and standard values for the item in the addeditems folder. As I understand it right it should mean that the item with all the changes is in package, but for some reason they are not applied.
By default, TDS will NOT remove anything from Sitecore. You need to setup the child item synchronization settings and enable removing/recycling items in the build property page for the target environment. Please see:
http://hedgehogdevelopment.github.io/tds/chapter4.html#deployment-properties
http://hedgehogdevelopment.github.io/tds/chapter4.html#build
http://www.hhogdev.com/help/tds/deploymentproperties
For more information. I recommend that you use the deployment property manager window to make sure your templates are set to "Always". Tell TDS to put items in the recycle bin in the build property page and backup your target database before trying this for the first time. Once you get the hang of the deployment properties, it is pretty easy to manage.
You can review the actions applied from an .update package within the update installation wizard itself, right after applying the package. Click the button labeled "Installation result>" and try filtering the list to look for warnings and errors related to your item.
Another option is to review logs located at ~/temp/__UpgradeHistory/ folder. In particular, I would look at the messages.xml file.
Related
When running the Azure DevOps Projects List GET, one particular Project is excluded from the results. I cannot find any different settings. I am the admin of it. I can add new projects, and there were projects I created before it, that all show up in the results. It's the API call as documented here: https://learn.microsoft.com/en-us/rest/api/azure/devops/core/projects/list?view=azure-devops-rest-5.0
I cannot find explanation of why a project is excluded from the results aside from Project State, which I have troubleshot already.
I've already tried running the GET API in the browser and I do not return the missing project. I have tried creating another project in the same manner and it appears in what is returned. I have added an argument for Project State = All, and that does not improve the outcome.
Under what circumstances is a project excluded from these results as a standard (undocumented) constraint?
edit: I am a project admin, and I have access to the default project team. I have tried recycling things in the background by changing the Project Name back and forth, and having myself removed as Admin and added back in, with no change in the API response.
edit: It seems like the more important question is how to force Azure DevOps to cycle the 'lastUpdateDate', when it's currently set to a non-date.
This may be due to the fact that the result set for the call is 100 entries. So you either need to use the continuationToken to get the next 100 entries, and so on. Otherwise, you can also use the $top query parameter:
https://-collection_url-/_apis/projects?api-version=5.0&$top=200
I have Eclipse Neon with TFS plugin
When I check pending change and I relate to work item
The problem is that the Check in Action by default is Resolve and not Associate
How do I change the default?
All I found online is about visual studio which didn't help me.
(Registry not worked HKEY_CURRENT_USER\Software\Microsoft\VisualStudio**11.0**\TeamFoundation\SourceControl\Behavior #ResolveAsDefaultCheckinAction = "False")
Unfortunately, this could not be achieved in team explorer everywhere(TFS Eclipse plugin) for now.
As a workaround, you could edit the Work Item Template definition for the types of work items you are using (Bug, Task, etc.). Then remove the Check-In Action from the Work Item Template (WIT). Once the WITs have been updated into your team project this will be available for all users. Now when you add a related work item, the only option available is Associate. However, this solution has some pros and cons. Below is a few to consider:
Pros
This change only has to be made the Team Project and nothing has to be done on the clients.
If your team not resolve the work item, removing this option is not a big deal.
Cons
This would need to be applied to all current Team Projects and would
need to update the Process Template for future Team Projects.
This removes the Resolve option for users, so there is no way to perform this action anymore.
More details about how to remove resolve option, please refer DaveShaw's answer in this question: How to disable auto done status for task in checkin
I am publishinga Nuget package in incrementally iterative and highly-frequent mode.
What is the best place to put the change-log? Is it the [Description].
Or is there a specific place to put the change-log in a reverse chronological order?
I would eventually push this package to [ProGet] too...and if there is any practice around it regarding change-log?
You can put this value in the <releaseNotes> element (from the NuGet .nuspec reference):
A description of the changes made in each release of the package. This
field only shows up when the Updates tab is selected and the package
is an update to a previously installed package. It is displayed where
the Description would normally be displayed.
Since this is interpreted by the NuGet client and not the server, the ProGet handling is the same.
We're using RTC/Jazz SCM and I'm the Configuration manager in our team...
So I setup the RTC/Jazz SCM, I created a component, I created a stream, I created a repository workspace and a local workspace, the repository has the stream as flow target.
After I shared an eclipse Project I did some other changes and my component grew and grew...
I made baselines whenever I made a build. Now my coworker are asking me: how can I know if my file is in this or that build, and I'm not sure how to answer their question, so
How can you show all BASELINEs on a FILE?
The article "Practicing source control archaeology with Rational Team Concert" shows that a file History view only shows change set, not baselines:
If your change set is linked to a work item, that work item id will be part of the change set title.
And it is better to consider work items instead of files, because for a given build (see this thread), you can use the "Work Items link",the one in the Contribution Summary section of a build result.
You can then have a look at "Work items included in this build": work items whose change sets are included in the configuration being built.
This differs from "Work items reported against this build" (top right corner of a build result), which are ones that you explicitly associate with the build (commonly, work items that created after the build was completed, that refer to information generated by this build, such as errors reported in the build results).
So there isn't a direct way, but looking at a build result can help find a work item you know your file is a part of.
Scott Cowan adds in the comments:
you can easily get to a change set's work item to find it's build results by:
selecting the file version in the History view and
in the context menu select "Related Artifacts > Open".
Whenever I try to import a workflow from Dev/Test environment of a versioned repository into Production environment which is also versioned, I get a option where it asks me if I want to Check in or continue without check in. What happens if I do not check in and continue? Will all the objects used in the workflow will not be checked in or is it just the workflow which will not be checked in? I am asking this because, it will be double work if all the objects used will not be checked in including the Workflow, then, I have to go one by one to check in the objects. If I check the check in option for the workflow, after importing the Workflow, the integration service is left blank and when I run it, it is pointing towards the Integration service not mentioned error. For this I generally check out the workflow once I import just to mention the Integration service name. I do not think this is a good practice. Any advices on this will be greatly appreciated.
Thanks
Dhruuv.
Will all the objects used in the workflow will not be checked in or is it just the workflow which will not be checked in?
The objects that will be left in the checked out state are:
the workflow,
the new objects (i.e. they were not present in the Prod repository before the import from Dev/Test),
the modified objects (i.e. they were present in the Prod repository but were overwritten because you chose the Replace option).
I have to go one by one to check in the objects
You don't have to check in every individual object - in Repository Manager open the Versioning menu and choose the Find Checkouts... option. All the checked out objects will be listed - you can select them and check in all of them at once.