I am moving from TFS 2015 to Azure DevOps in the cloud.
Following the migration guide I have done the following:
TFS 2015 -> TFS 2018 -> DevOps 2020.
When running the Migrator tool I am getting an error. The OTB process has errors in them.
If I don't care about the changes made in my process is there a simple way to get to the OTB process?
The Process validation error in TryMatchOobProcesses.log file would block your projects
from landing in the inherited process model(OTB process). But You don't have to fix these errors. They will not prevent you from doing an import. And all your customizations will be imported to Hosted XML process model.
See below extracts from the Process template validation.
If the project was created with the Agile, Scrum, or CMMI process template, and was never customized, the project will use the Inheritance process model. In all other cases, the data migration tool considers the project as customized, and the project will use the Hosted XML process model.
TryMatchOobProcesses.log - Lists for each project the target process model - Inheritance or Hosted XML. For projects that are set to target the Hosted XML process model, it explains why they are considered to be customized. You don't have to fix these errors, but they give you guidance what to do in case you want to migrate into the Inheritance process model
And now DevOps 2020 services supports Moving from Hosted XML Process to Inherited Process. See the below official documents for more information about what you need to pay attention to when moving to Inherited Process.
Clone a Hosted XML process to an Inheritance process
Change a project from Hosted XML to an inherited process
So according to Document and the Migration Guide(Page-33), you can just import the process without fixing the Process validation error in TryMatchOobProcesses.log. After the process is imported to Hosted XML process. Then you can change it to the Inheritance process.
Related
we upgraded a TFS2017 to Azure Devops Server 2019.
We had a custom XML process template on TFS2017 that we want to migrate to inherited processes. But we cannot see this process template in the process page. We only see the inherited processes (Agile, CMMI, ...) and the basic XML templates which where migrated ("Microsoft Visual Studio Scrum 2013.3", "MSF for Agile Software Development 2013.2", ...)
There is a project with this custom template and we can update the process with WIT commands.
Does anyone know how to make this custom process visible in the process page? then we will be able to migrate it.
everybody.
We have just successfully migrated from ADServer 2019 to ADServices.
We have a single custom process template that is used for all Team Projects. After migration, each team project has its own Process Template, as expected.
However, as all migrated Process Templates are equal, I would like to group all Team Projects in a single Process Template.
In order to do that, I do these steps:
Go to Organization Settings
Select Process
Click on one of my hosted process templates
Click on "Projects"
Click on "..." and select "Change Process"
A pop up appears, where I can select the target process I like to change. It's important to note that all hosted migrated process seems to be avaliable for the change.
When I select another hosted process, and click "Ok", the message "The feature is disabled. Contact your Azure DevOps Server administrator." appears and the change can't be done.
I have been looking how to enable this feature with no success.
Has anyone had this situation?
If is not possible to do that, is there any way to import the future changes of my process template via command line, in order to update all my team projects ?
Thanks in advance for the help.
Regards,
Alba
We evaluated this situation with MS and the answer is that there is no way to make this change of process template between team projects belonging to different hosted process template, even though the process templates are equals.
As we cannot change our Process Template to hosted process by now, our solution was making a script using AD api, in order to make a bulk update of all process templates for all our team projects.
See https://learn.microsoft.com/en-us/rest/api/azure/devops/processadmin/processes/import%20process%20template?view=azure-devops-rest-6.1
From the screenshot, you were trying to change the process used by the team project from a hosted xml to an inherited process. For your scenario, you need to
cloned your Hosted XML process to an inherited process.
Change a project from Hosted XML to an inherited process.
An useful blog for your reference:
https://devblogs.microsoft.com/devops/moving-from-hosted-xml-process-to-inherited-process-ga/
I have a requirement to change the layout of the Task in Azure DevOps Server 2019. I want to relocate the "Details" section under the "Staus" section. I tried using the Process editor via VS 2019. But doesn't work published WIT show no modifications. Can anyone guide me through this?
Layout change I did:
Additional Note:
I tried following the inherited process model but got stuck. According to this article some links are missing on our DevOps Server 2019. I logged in as the administrator of the DevOps server. Please refer to the screenshot attached.
In Azure DevOps, we do have two process models,On-premises XML process model and Inheritance process model.
For Azure DevOps Server 2019, you have a choice of process models. When you create a project collection, you'll need to choose between On-premises XML process model and Inheritance process model.
Using the Process editor via VS 2019 only apply to On-premises XML process model.
If you are using inherited process, you need to do the customization in web portal directly-- Customize the web layout for a work item type (Inheritance process)
More details about the customization of these two models:
About process customization and inherited processes
On-premises XML process customization
Trying to make my life easier, Currently we have 4 developers working in Visual Studio 2012 and we are using TFS 2012 for source control. The project we work on is a multi-tenant web application (single source directory with multiple dbs) that is a mixture of legacy, asp and vb6 com components, coupled with new C# code. We use TFS for source control and for managing User Stories and Bugs. Because of the way our site works it can not be ran or debugged locally only on the server.
Source Control is currently setup with a separate branch for each developer that's working directory is mapped to a shared network path on the dev server that has a web site pointed to it in IIS. Dev01-Dev05 etc. The developers work on projects in their branch test it using their dev website, then check in changes to their own branch and merge those into the trunk. The trunk's work space is mapped to the main dev website so that the developers can test their changes against the other customer's dev domains to test against customizations and variances in functionality based on the specific dbs the are connected to.
Very long explanation but basically each dev has a branch and a site, that are then merged into the trunk with its own site.
In order to deploy our staging server:
I compile the trunk's website via a bat file on the server
Run a windows app I built to query TFS for changesets associated with
specific WorkItems in a certain status, and copy all the files for
those changesets from the publish folder to a deployment folder.
Run another bat file on the server to use RedGate's Deployment Manager
to create a package from those new files
Go to the DM site on our network to create and deploy that release (haven't been able to get the command line tools to work for this, so I have to do it manually)
Run any SQL scripts that have been saved off in Folders that match ticket numbers on each database (10 or so customer dbs) to support the release
I have tried using TFS automated build stuff and never really got it to build the website correctly. Played around with Cruise Control also with little success. Using a mishmash of skunk works projects to do this is very time consuming and unreliable at best.
My perfect scenario would be:
Gated Checkin, Attempt build/publish every time a developer merges into the trunk, rejects and notifies developer if the build fails.
End of the day collect the TFS Items of a certain status and deploys files associated with them to the staging site
Deploy SQL scripts for those TFS items across all the customer dbs in staging
Eventually* run automated regression UI tests, create new WorkItems or emails to devs if failed
Update TFS WorkItems to new state so QA/Customers know their items are ready to test in our staging environment
Send report of what items were deployed successfully
How can I get here so that I am not spending hours preparing and deploying releases to staging and eventually production? Pretty open to potential solutions, things that would be hard to change would be the source control we are using, can't really switch to subversion or something else so we are pretty stuck with TFS.
Thanks
Went back in and started trying to get TFS to build/publish my web solution. I was able to get a build to complete successfully. adding msbuild argument /p:DeployOnBuild=True and setting the msbuild platform to x86 seemed to do the trick on that.
Then I found https://github.com/red-gate/deployment-manager-tfs which gives you a build process template to do the package and deployment using the redgate tools. After playing with that for a bit I finally got it to create, package and deploy my build to our staging environment.
Next up will be to modify the template to run some custom scripts to collect only the correct items to deploy, deploy all the sql files and then to set the workitems to the appropriate statuses after completion.
Really detailed description of your process. Thanks for sharing!
I believe you can set up TFS to have gated check-in on a single branch, which if you can setup on trunk would make sure that the merges built successfully. That could trigger msbuild, if you can get that working or a custom build job.
If you can get that working then you'd be able to use that trunk code as the artifact to send to Deployment Manager. That avoids having to assemble the files for deployment through the TFS change sets, as you'd be confident that the trunk could always build.
Are you using Deployment Manager to deploy the database from source control as well as the application?
That could be a way to further automate the process. SQL Source Control and SQL CI allow you to source control the structure of a database, keep a database up to date on each check-in, and run database unit tests. They also produce database packages for Deployment Manager, so you can deploy a release that contains both the application and the database.
If you want to send me the command you're using in step 4 to deploy the release using Deployment Manager I can help out with that. The commands I use are:
DeploymentManager.exe --create-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1
DeploymentManager.exe --deploy-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1 --deployto=CI-Environment-Name
That will create a release version 1.1 using the latest available packages for that project. You can optionally specify the package to be used when creating the release with
--packageversion=<package name>=<version>
--packageversion="application=1.5
We have our build and deployment scripts set up in TFS 2010.
But we are also evaluating indeo Build Master. Has any one used this before?
Also, in general, for a full .NET house does it makes senses to have another SCM management tool?
Here is the link for inedo
I found this while researching Inedo's BuildMaster as well. We're a .NET/TFS shop, and BuildMaster solves all sorts of different problems.
Here's a blog post I found that discusses the differences:
http://blog.inedo.com/2011/06/06/how-does-buildmaster-compare-to-team-foundation-server/
We're using the free version of BuildMaster and may upgrade to enterprise once we use it for other projects.
Buildmaster has a TFS plugin that helps grab builds from TFS Builds. We use Gated check-in to ensure the code builds and Buildmaster to package the build for 1 click to deploy through the environments. Buildmaster has a fix forward approach (as in, no roll backs), where you create many builds for a release and each propagates through each environment and when 1 or more exist in say QA and have not moved to Staging, they will both be moved to staging at the same time, but in order, thereby ensuring all artifacts move through every environment.
Prior to Buildmaster, we used an xml driven PowerShell script that worked well, but Buildmaster agents saved us from remote desktop script execution. Our Powershell script has 1 advantage that Buildmaster does not yet have. We used the xml configuration file to hold application configuration file information, including file names, relative paths and xpath settings to inject values, xml fragments and remove xml nodes from configuration files coming from source control. Buildmaster uses template configuration files stored in Buildmaster, with tag replacement for each environment. This results in high maintenance should anything change in a configuration file, such as additional environment non specific sections being added, which would require creating the template again.
Buildmaster does have a custom action that allow you to run executables, so theoretically, you can run your own commands to perform functionality that Buildmaster does not have built in, but this is not ideal.