I recently migrated from Bitbucket to a Github account in my department.
In Bitbucket, I can create a team deploy key and use it across all projects.
In Github I couldn't find this option. I found that I must create a "machine user" and add it to my team. This seems a little jerry-rig and I would also lose a team seat.
How to overcome this and create an organization-level deploy key?
EDIT: I have two servers that use 3 repositories each. I want to be able to deploy the 3 repositories in both servers.
Related
We have two Azure DevOps Organizations,
1. Development
2. Client
I would like to know if we can synchronize Azure DevOps Repos from one organization (Development) to different organization (Client) in a secure way?
If it is possible, what would be the best way to sync from one organization to another securely?
NOTE: We are able to manually clone the Repo from one to another organization for the first time with the help of PAT and GIT Auth but the problem arises when we want to update or re-sync the code. We have to manually re-import the repo (By deleting the existing one) to make changes.
We need to do this programmatically and to another organization.
Azure DevOps Repos synchronization between Organization
Sorry but as I know there's no such out-of-box feature available in Azure Devops Service.
There're similar user voices here: Sync between projects in same org and Automatically Sync Azure Devops Repos with GitHub Repos. Usually one organization is responsible for one product, so Azure Devops doesn't recommend cross-organization actions. But if you do want this behavior in your scenario, you can use these two directions:
1.Try free Git Tools for Azure Devops extension from Martin Hinshelwood. Some steps about how to use it:
Install it in your Development organization, it contains one Publish Git Repo task.
Create a new classic build pipeline named SyncRepos, add the Publish Git Repo task in it.
(Yaml pipeline also works well, but since this is one pipeline in which only exists one task, classic pipeline is enough)
Configure the task. We only need to configure the git repo url, so it's quite easy.
Assuming the name of same repos in another organization Client is ReposToSync, and this repos is in ProjectA. So the url you should enter in pipeline(in organization Development) should be:
See this: https://anything:PAT#dev.azure.com/Client/ProjectA/_git/ReposToSync.
(You should use a PAT which has repos-related permissions. I used Full Access one to test it easily but it should be much better if you create a PAT scoped in repos permissions. It's more secure !)
Now set the trigger, enable the CI and add all the branches into filter.
Yaml pipeline is better in step4 cause it supports trigger all branches with wildcard *. See this.
Now in Development organization, when I have any change in master and qwe branches, it will automatically trigger the pipeline to run. Then the task will sync the changes in Development's repos with repos in 'Client' organization.
Any change in Development org will start a sync, if you want to same behavior in 'Client', you also need another similar pipeline in 'Client'. And, yaml pipeline with wildcard is better if you want the pipeline to monitor newly created branch.
In additions: Apart from using the task from extension, we can also use git commands in CMD task if you're familiar with those commands.
2.Feel free to post a new feature request to our User Voice forum. If you gets enough votes, the request's priority increases and the team would consider it seriously.
Hope all above helps :)
Update1:
No matter git commands or extension, if we want to make it more secure(avoid using PAT or other secrets directly in task), we can use secrets to store the important info like PAT.
1.See create secret variable in Variable Group, then link the variable group, after that we can use $(MyPat) in task and it won't be displayed in log.
2.Also you can consider using Azure Key Valut. Related doc: Link secrets from an Azure key vault.
Today I tried a way of doing it I found in a blog post and it worked perfectly (and is tremendously easy to do).
Steps:
Create a PAT (personal access token) to your Development organization (I see you already have one so skip this step)
Go to the target repo in the Development organization, click clone and copy the url
In the Client organization import the repository with the url you have copied and with your PAT (same here, I think you already did this so skip this step)
Now clone the repo to your computer from the Client organization and add a remote to the repo in your Development organization. If you don't know about remotes, this page could help: Managing remote repositories
After this, you will be able to push and fetch from the Development organization's repo.
Source: Azure DevOps Fork Repos between two Organization - Michael Ghebremedin
I am in a microservices project where we are creating around 120 microservices. How do I configure azure devops for this project? Do I have to create a new project for each microservice? I would like to keep the dash for project monitoring
I would recommend that you create an organization and a project.
Then you can use create a git repository for each microservice, 120 microservices in 120 repos.
You can read about how Microsoft uses git here.
TL;DR version quoted below.
Mono Repo or Multi-Repo with Git
It's worth pausing to reflect that this isn't the only way. While
we've elected to have a single monolithic repository (the
"mono-repo"), other products at Microsoft use a multi-repo approach.
Skype, for instance, has hundreds of small repositories that get
stitched together in various combinations to create their many
different clients, services, and tools. Especially for teams embracing
microservices, multi-repo can be the right approach. TFS/Azure DevOps,
like many products at Microsoft, began as a monolith, and its code
organization reflects that
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
We have an application that is comprised of multiple distinct components (different functions / languages).
Is it possible in IBM Bluemix to use a single Track & Plan feature to manage the work items for the components but keep the source code in separate git repositories? For example, I would like to have one backlog for the overall application which is then backed by 5 separate git repos which house the individual components (project-frontend, project-backend, project-queue etc..).
If this is not possible does anybody have a pattern that has worked in streamlining the overall Track & Plan and still enabling the delivery pipeline / managing individual git repos? Ideally I'd like to centralize task management but keep the code distributed.
As of now, there is not a way to manage distributed git repos from a single Track & Plan project in an integrated fashion. That is not to say that it cannot be done manually, but you would need to link to commits in the remote repos in a given work item.
This can be done through the Links tab of any given work item and using the Add SVN Revisions or Add Related Artifacts. This would allow you to link to the remote repos (whether in IDS, GitHub, or private SCM tooling), while still leveraging Track & Plan as an overall planning repo.
Some of this is due to the way projects are constructed in IBM Bluemix DevOps Services today. A single project has the notion of a single git repo, a single Track & Plan instance, and a single Build Pipeline. Some of these requirements are expanding, but the platform provides integration capabilities to work with your code the way you need to right now. For example, project owners can build from remote GitHub repos in the project's Build Pipeline, so that code can be managed as you see fit, but built and deployed on IBM Bluemix.
Some time ago I started to use the Bluemix platform to develop PHP services that were used by a mobile application. After a while, I realized that it would be very useful to have a repository to which I can connect multiple Eclipse IDEs and work on the same application.
I already had a Jazz ID which was used for the work projects; I am talking about using Bluemix+Jazz for personal projects.
When I first connected the Bluemix ID with the Jazz ID, everything was well. But I realized that it might be a conflict of interest because I am using the same Jazz ID for both work and personal projects.
My question is: Is there a way to use a new Jazz ID in Bluemix?
It seems that the connection between the two IDs cannot be changed from Bluemix, DevOps or Jazz.net.
Costin, thanks for your interest in IBM Bluemix and the IBM Bluemix DevOps Services. Like Lauren has said, you'll probably want two IBM IDs, one for your work email address and one for your personal. They ultimately can be associated with two Bluemix orgs, each associated with a different DevOps user.
You'll need to decide which Bluemix org you want each of your apps to live in; the corresponding user should own the app's Git repository. To move a Git repository, you can use either of these approaches:
Use the repository's "Download the contents of this branch as a zip file" button to download the contents. Then as the other user, create a repository and import the zip file.
Share the repository with the other user, fork as the new user to get a copy.
Once you have the code in the other user's repository, redeploy to that user's Bluemix org.
Once you have everything where you want it, delete the stuff (apps and repositories) that are not where you want them.
One option is to create a new IBM id that is linked to your personal e-mail address. The IBM id could be used to sign in to Bluemix and DevOps Services.