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/
Related
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.
I inherited a project a while back that uses Azure DevOps Pipelines for deployment and when I want to edit the pipeline I have access to a wizard to walk through the tasks, triggers, variables, options, etc.. I then set up a completely separate project for a different organization and when I go to create a new pipelines it's only allowing me to use a YAML script. I don't see a way to run through the wizard.
Also, in the previous project under Pipelines I have sub menus for Pipelines and Environments. In the project I just set up I don't have these choices, only Builds. So it seems like I may be using an older version in the original project, I'm not sure and I can't seem to find a way to change the version.
Is this wizard no longer available for new projects? Is there a setting somewhere or something I am missing to gain access to it or do I have to use YAML only from this point on? If that is the case, is there a way to upgrade the old project to this version (I want to stay consistent)?
Is this wizard no longer available for new projects?
No, you just facing the different design of azure devops.
You can only create the YAML.
The page you can see the tasks, triggers or other tabs is the design of Classic editor pipeline.
Please choose Use the classic editor after you new pipeline.
Click Continue after select the source (the repository and the branch) for your project.
At the next step, you can choose Empty job, also you can add some tasks.
Note: do not select Configure as code. It is YAML.
Now, you can see the tabs like tasks, variables, triggers and etc.
Could not seen Pipelines and Environments.
These two tabs are the new UI design which published in recent sprints. And we provide it by enable Multi-stage pipelines in
Preview features panel.
I assume you did not enable this feature and just saw Builds there.
Click your head account which located in right corner, then choose Preview features:
Then enable Multi-stage pipelines.
After enable it and close the panel, this page will be re-load automatically. Then you will see Pipelines and Environments in the left wizard panel.
Our main project is hosted and managed on VSTS online. We are managing the work using Features, User Stories and tasks. In addition, the code is managed and stored in Repos. We are working with pipelines and such for CICD. Last, we installed some extensions downloaded from the marketplace.
Currently, we are running on the build-in Agile process. We would like to create an inherit process and move the project to it. I’ve done that in the past but without the project using CICD.
The question is, can we do that safely without harming or endangering our code and CICD operations?
Thanks
The CI/CD processes not related to the Work Item process. you can move to inherited process template without harming or endangering your code and your CI/CD pipelines.
Unless you touch the work items during the build (with custom scripts/API) and change fields etc. so you need to update the scripts (e.g. you change a field called "A" and in the new template is "B").
I am trying to build a Project Server workflow using SharePoint Designer 2013.
The workflow itself is working. It can create a task in the Project Server task list and approving it progresses the workflow.
However, if you click "Additional Workflow Data" the history is always empty. I have been able to create a custom event to log in the history via designer, but I am looking for the true history of the workflow. In 2010, the history would show it entering each stage and other logging data. My 2013 workflow history shows nothing.
I have verified the account has permissions to write to the list. I have checked the IIS logs to see the workflows are running. I have checked the project server permissions and groups for the workflow proxy account. I have ensured "Workflows can use app permissions" is activated for the PWA collection. I have also tried "Copy-SPActivitesToWorkflowService" cmd to see if it needed to installation needed to be repaired. I have restarted the workflows, republished, bounced the boxes, but still not workflow history!!
Does anyone know how to resolve this issue or have other suggestions on where to look?
You need to use an 'Action' within the Workflow called 'Log to History List' and enter what you want the log to say at the point where you have added the Action.
The sticking point comes from a differences in versions.
In Project Server 2010, the workflows showed default actions and processes. In 2013, you cannot see all the various behind-the-scenes actions.
Any actions which you want to be able to trace, for example, when the project entered the stage, must be added into the custom workflow manually.
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