2 developers are updating the same file in the same project. the last update gives an error. Because the first updated codes are not found in the file that the 2nd developer is trying to update. Migrate error.
This way, the first updated user's codes are deleted. How can I solve this problem?
Azure devops Repos style.css
a{}b{}
Developer's style.css (First updater)
a{}b{}c{}d{}
2.Developer's style.css
a{}b{}e{}
updated Azure devops repos style.css
a{}b{}e{}
c{} and d{} disappeared
Your team needs to select and adhere to a version control workflow that meets your needs and that is supported by Git (the distributed source control you have apparently chosen). I suggest starting here: Azure Repos Git tutorial.
You might even question whether Git is the appropriate source control choice given your needs. See Choosing the right version control for your project
Related
On my private projects I am using Git. I have installed GitLense for Visual Studio Code, which is awesome. I can click on a line, and see who changed it when within which changeset. See red arrows where I have deleted code and so on.
I have a VS2017 project using azure DevOps. I have read about CodeLense, which does not apply on my C++ projects, even in C# it is barely helpful.
Does someone know a similar extension here?
You could install the extension Code Compare to check the file changes.
Also, if you are using Azure DevOps and clone the repo local, we could open Team Explorer->Changes->Actions->View History->select commit and right-click->View Commit Details to check the changes, you could refer to this doc for more details.
The problem statement: In my project, GIT HUB is being used as a version controlling software. Here we need to check whether all artifacts are being checked in by all developers. So the plan is to consume if any service available in Git Hub to get access of all the current checked in artifacts from that branch. Once we have that list ready then it will be matched with entire list of artifacts( already have a list) those were developed. It will help us to prepare the delta/sub set of artifacts those are not checked in.
Any help/suggestion/better approach is highly appreciated.
Cheers!!
Nilanjan
I recently migrated to a git monorepo strategy where I keep all my APIs and applications, I'm also following trunk-based development using Azure DevOps.
Since each application lives on its own folder in the root of the git repo, I was able to enable branch policies and PR requirements driven by that folder. For example, request PR reviews from the Mobile team to every PR that modifies anything inside the MobileApp/ folder.
Likewise, I was able to configure build and release pipelines to deploy the correct application only when there are changes to its folder to every environment.
Now, I'm having an issue when deploying to environments that require approval. Previously, I was able to use the Commits and Work Items summary in the approval stage, to know exactly what are the work items that the release is pushing to production but because now every application lives in the same repository, I'm getting a report with all the commits since the previous pre-prod release, regardless the application:
Only the first commit modifies any files inside the MobileApp/ folder. The other 4 commits belong to different applications and teams.
Is it possible to only show the commits/work items filtering by the folder? For example, the same way Azure Repos work if we select a folder and click to see the history:
If not, can you think of any way to get this information while taking a mono repo approach?
Related feedback:
Q: Will you let us manually pick or attach related work items to a pipeline or Release?
A: No - Closed.
https://developercommunity.visualstudio.com/t/Add-Related-work-items-to-BuildsRelease/740058?space=21
Sep 19, 2019
Q: It is a bug you don't support path filter, like build trigger, when associating commits to a build/release.
A: Not a bug - Closed.
https://developercommunity.visualstudio.com/t/azure-pipelines-related-work-items-not-considering/1063605
Jun 03, 2020
Q: Will you add a new feature to support path filters, so monorepo pipelines don't list all commits to all folders per build/release?
A: Ignored, now closed automatically because of age.
https://developercommunity.visualstudio.com/t/Azure-Releases:-Add-a-path-filter-featur/1015157?space=21
May 01, 2020
Q: Support same path filter as triggers to filter commits. Filed by MSFT employee (as a suggestion, converted from earlier bug)
A: Ignored, now closed automatically because of age.
https://developercommunity.visualstudio.com/t/related-work-items-not-considering-path-filter-in/1076618
Jun 12, 2020
Conclusion: Pipeline team has ignored or closed this many times. Looks like this feature is not going to happen. But if you can benefit from this feature I hope you'll vote up this answer. I've marked it "Community wiki", please add any new related feedback items you find.
Is it possible to only show the commits/work items filtering by the
folder? For example, the same way Azure Repos work if we select a
folder and click to see the history:
Are you trying to get a path filter or something similar to that in Release=>Stage log=>Commits page? If so, I'm afraid there's no such out-of-box feature available for now.
To check Commits related to changes in specific folder, you can navigate to Azure Repos Files page to check the history. As for workItems related to the commits, you can find that in Commit=>Details:
But if you do want a path filter feature in stage-related commits and workitems(in your first page) to be added, try submitting a feature request in our user voice forum. The team there would check your idea and consider about that. Hope it helps :)
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
I'm using Visual Studio Team Services to build my project which is stored in GitHub (here). The master branch contains multiple projects which make up the solution. Amongst those are a WebAPI project and a Cordova project. I need to build those using two separate build definitions in VSTS.
Previously I had set-up my build definition and used the branch filters to filter on what had been pushed to the repo. For instance:
master/src/API
This worked, but it doesn't any more. It seems as if the underlying code has changed. A filter of 'master' still works and I understand how this feature is probably meant to filter specifically on branches and maybe not on folders within the branch?
It's not a huge problem, but at this time all of my builds will trigger with every check-in, even if nothing changed in the meantime for that source code. So I'm not wondering what a good solution for this issue would be:
Put every project in it's own branch. Seems like a workaround
Some other filter option or maybe another syntax or something?
Leave it as it and don't worry about the extra builds (but that itches, you know...)
Anyone running a similar set-up?
Path filters is not supported for VSTS GitHub CI Build, it is available for Git CI Build on VSTS. You can vote this user voice: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/15140571-enable-continuous-integration-path-filters-for-git
The workaround is as you said that put every project in its own branch.