We have the same enterprise app that we sell to multiple customers. The source for the app is hosted in a private Azure DevOps Repo. But we manage each customer's implementation using a separate project for each customer with it's own work items.
Currently we have no way of linking commits to the Source in the Repo project to work items in the implementation project.
We don't want to have the repo in each implementation since that would be redundant and challenging to keep in sync.
Is there a way to handle this inside DevOps?
Currently we have no way of linking commits to the Source in the Repo
project to work items in the implementation project.
For this issue, when you commit to the source in the Repo project, on the Commit page, you can choose to link to work items in other projects.
Or you can click Add link in the Development field of the work items in other projects.
Then on the Add link page, select the Commit link type, select your source repo, and select the commit you want to link.
Related
My company has few repositories hosted in GitHub with some .NET stuff, but uses ADO Pipelines for the CI/CD. Is it possible to use azurepipelines-coverage.yml (link to Microsoft documentation on it) to check pull request's code coverage? Or is that feature for ADO repositories only?
Would really appreciate any help!
I've added azurepipelines-coverage.yml to root folder along with main pipeline (new simple repo with simple code, few tests and repo), however, not sure how to "use" it, as there's no option to add it to PR check (similarly to ADO repos branch security).
I want to create a workflow for moving issues in GitHub project boards such as:
When someone creates an issue it moves to the project board "To do".
Once the developer creates a branch with issue name then the issue should move to the different project board "In Progress"
Once the developer finished his work and merge it with the master branch then it should move to project board "Done"
I got some workflow for creating a branch for issues and move-in boards but I am unable to create the flow.
Github API
There is a full project section in the Github API with endpoints you could use to customize your workflows.
Note: here is a similar question
Github Actions
There is also a Github automate project action on the Github marketplace, to use directly in your workflow if it match your context.
Note: There may be others on the github marketplace
In a project I'm planning to have following items/projects:
.Net Server, Ionic App, Angular Website and a C# Admin tool.
At first I made a project, created one repository and folders; Server, App, Website and AdminTool in the root. But as I want to use pipelines and structure my code best possible way, I'm thinking it might have some advantages creating a repository for each project, in my project.
This way I will trigger exactly the pipeline of the project which needs to be build and it might be more module structured.
But I also see the disadvantage of having to push multiple times for the same feature - Each for each involved project (e.g. IonicApp and Server). This way it's not that clear what is made across projects for one feature, which could be seen in one push.
Which way to structure this would you recommend?
Generally, a Git repository on Azure Repos should be no larger than 10GB. This aims to ensure reliability and availability for all customers.
If you put too many projects into one repository, and these projects may also contain some large files, it may dramatically increase the time to checkout, branch, fetch, and clone your code. This could bring you a bad experience with Git. For more details, you can see "Git limits".
So, in your case, maybe you can consider using Submodules.
Create a repository for the main project.
Create a repository for each sub-project.
Set the repositories of sub-projects as the submodules of the main project's repository.
For the source codes of the features that are involved in multiple projects, you also can set up a specific repository for each feature, and then set the feature repositories as submodules of the involved project repositories.
With this way, you can set up the pipeline for each repository. And you also can using the "pipeline-completion triggers" feature when you want the changes in the submodule repositories also can trigger the pipelines for the repositories that is using the submodules.
A separate repository for each project is highly recommended and considered best practice.
With this you will have benefits, like;
smaller sized repos,
every project integration with CICD separately.
Because at the moment you will be updating single app project, so why to bother other running projects
I have created a project 'Company 1' and I want to create subproject inside that project like 'Deploy VM', 'Deploy App' etc. so I can put all 'Company 1' related code inside one project. And I can create multiple builds inside the same project.
But I am not seeing the option to create a sub-project. How can I achieve this in Azure DevOps? Do I have to create multiple repositories in the same project or there is another way to do this?
Thanks.
The term Project in Azure DevOps is a bit misleading. It would make more sense if it were called "workspace" or something like that. Each project can contain a very large number of repositories, build/release piplelines, team spaces, area paths, etc.
In fact, my entire organization lives primarily in one Project space with hundreds of repos and build definitions + dozens of separate team spaces.
Creating separate project will fully segregate concerns, so it's not a good idea unless you want true, full separation with no relationships to the others.
In your scenario, I recommend creating separate repositories and build definitions in the same Project space.
There is no sub-project in Azure Devops. Why don't you create a branch for your repo? You can pull/push codes for the new branch.
Git branches aren't much more than a small reference that keeps an exact history of commits, so they are very cheap to create. Committing changes to a branch will not affect other branches, and you can share branches with others without having to merge the changes into the main project. Create new branches to isolate changes for a feature or a bug fix from your master branch and other work. You can add some new features in one branch.
You can also build target or multiple branches using Azure Pipelines or TFS. Please see this document.
I have got a project in an old org (from VSTS), that I want to move to my new one.
I can't see any options in Azure DevOps on migrating projects, or any information on the interwebs.
Anyone know how to do it?
If you just need to move repos, you can use the built in clone functions:
Go to the Azure Devops source repo -> Files
Click "Clone"
Choose "Generate Git Credentials"
Create the target repo in the target Azure DevOps
Choose "Import a repository"
Use the URL and credentials from Step 3
Done
This is not supported today. But this feature was planned to develop: make it possible to move a Team Project between Team Project Collections
If your Azure Devops project only tracks code versions using a single Git repo, hence no boards, user stories, tasks, pipelines, etc. then you can do the following:
Clone your project repo.
For example with Visual Studio.
You don't need to clone if you already have a local repo.
Destroy the association with the remote.
For this typically, you need to open a command line prompt in the folder that contains the .git database folder, most likely the solution folder of Visual Studio and type git remote rm origin.
Here is an example using git bash showing the content of the solution folder, including the .git database and the *.sln Visual Studio solution file:
Open the solution with Visual Studio if not already done.
It should now show that you have many commits waiting to be pushed to a remote. For illustration purpose, my toy project only have 8 commits in total.
Click the up arrow and choose your new remote, say a brand new Azure DevOps project, in the organization of your choice, then push.
You are now done cloning the project in another organization. If needed, then destroy the project in the old organization to complete the "move" operation.
There are 3 projects that I know of to achieve this.
A paid for option by Ops Hub -
OpsHub Visual Studio Migration Utility
An open source tool that requires making changes to the work item process template - Azure DevOps Migration tools
An lastly an Unofficial but still written by Microsoft tool to create Azure DevOps project templates - Azure DevOps Demo Generator & extractor tool
With the last one (the Demo Generator) you extract the project as a template, then apply it to the new organisation. As it is a tool for demo's there is no support provided and in my experience it works for simple projects but falls over on anything complex.
Expanding on others' answers, this post regards Pipelines.
Azure DevOps API
Migrating nearly all aspects of a project across organizations is doable, but it is a lot of manual work using the Azure DevOps API. The link below shows you all the end points, variables, etc. From there you'll probably want to write a Power Shell script and do a couple test runs to a dummy Organization.
https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-6.1&viewFallbackFrom=azure-devops-rest-6.0
In App options
If you avoid the API, there is no way to migrate pipelines that preserve build or release history, but you can preserve your configurations and processes by going into your Pipelines and selecting View YAML. From here you can either take this away as notes to recreate the GUI steps in your new org/project location, or actually adopt the YAML standard in your git repository.
I do not believe there is a way to migrate pipeline variables outside of the API. However, you can move the variables to Azure Key Vault and change your pipeline settings (YAML) to reference values from key vault. This is not a large amount of effort and is a nice process improvement.
Lastly, if you have any locally installed pipeline agents for releases, you will need to run the Power Shell script for your new organization on the boxes. Very simple 5m step, but right now the Agent Pools are not sharable across organization.
As #Frederic mentioned in his answer, we can actually easily do it with Visual Studio. I have done this without Visual Studio. The steps involved are below.
Add a User to Both Organization
Configure SSH Key
Update the SSH Key in Source DevOps and Clone the Repository
Check out all the Branches and Tags
Update the SSH Key in the Destination DevOps
Remove Old and Add New Origin
Push all the branches
The commands and detailed explanations can be found here.
BTW, if you need to change the entire Devops Organization tied to your personal Tenant (E.g. VS Enterprise Subscription) and move it to new Tenant, you can change the AAD and point it to the new one e.g. your EA Tenant on Azure commercial cloud.
Before you switch your organization directory, make sure the following statements are true:
You're in the Project Collection Administrator group for the
organization.
You're a member or a guest in the source Azure AD and a
member in the destination Azure AD
You have 100 or fewer users in
your source organization. Otherwise you will have to open a support ticket.
You may have to add the users back in destination org if they do not exist becuase they will loose access the moment you switch the AAD.
you could just download as a zip file and then download it to the destination repo