We're in the process of moving to Git, but currently our main codebase is on TFS.
We have a small project that needs its own build, but also needs to share a bunch of code that our main codebase uses.
Creating a new CloudBuild queue seems too heavy for this project, so we'd like to create its build in Azure Pipelines, but we're unsure if Pipeline builds support going to TFS.
Is this supported, and what's the best way to set it up?
If you want Azure Pipelines take the code from your internal TFS server so no, is not supported. Azure Pipelines can take TFVC code only if the repository exist in Azure Repos.
Azure Pipelines can take external Git repository, so when you will move to Git you can build your code without any problem even is not stored in Azure Repos.
Related
we are using Azure Pipelines to build and deploy various projects. We are using Enterprise Github service connection as our git repository source which we are using as part of the build pipelines that are running on on-prem AzureDevops build agent. We are then using on-prem hosted DevOps agents to deploy the service on our on-prem servers.
If we trigger a build we then receive an email notification about all the new commits which are included in the build. Is the same information (what commits are part of the build) included somewhere in the Azure DevOps UI? I was not able to find it and it's really difficult to then determine what I'm actually deploying our various environments as I'm not always the one who triggers each build.
Thanks
My organization recently changed from using personal GitHub accounts to using GitHub Enterprise Managed Users. Since that change our pipeline continuous integration (in Azure Devops) has stopped working. We can still run the builds manually without issue, but it isn't even attempting to start the builds automatically. I've created new personal access tokens for the pipelines, but that hasn't fixed the continuous integration. Does anyone have any suggestions on what I should look at to get this working again?
Instead of relying on user-authenticates service connections between GitHub and Azure Pipelines, I recommend switching over go the Github App for Azure Pipelines to control what repositories Azure Pipelines can access:
https://github.com/apps/azure-pipelines
That will drastically simplify access maintenance between GitHub and Azure Pipelines and will break the reliance on personal or enterprise managed accounts.
I wound up fixing this by going to the repository in Git Hub, go to settings on the repository, and then to Web Hooks. In there, the hook that Azure Pipelines uses had an error on it because when our tech group migrated the repo they did not bring the secret over. To fix it I just had to delete the web hook, go to the pipeline and a button appeared to restore the connection.
I am using Azure DevOps for my source control. I am creating Kibana Dashboard and wondering if it can be source control as well using Azure DevOps. My idea is:
Create Repo in Azure DevOps.
Write automated script(code) so it saves current Kibana Dashboard Saved Object into Azure DevOps.
In this way, I have old Dashboard in the repo. Has anyone done this? It doesn't have to be Azure DevOps, if you have any experience with it, please share with me. I am new to version control.
(https://docs.logz.io/api/cookbook/backing-up-kibana-objects-to-github.html < this was using github)
Kibana Dashboard version control?
The first thing to point out is that Azure devops is not a version control tool. It provides developer services to support teams to plan work, collaborate on code development, and build and deploy applications. Developers can work in the cloud using Azure DevOps Services or on-premises using Azure DevOps Server.
And Azure repo supports two types of version control methods: Git (distributed) and Team Foundation Version Control (TFVC):
What is source control?
You could set the version control type when you create the project:
After that, we could get the URL of the repo is also a git repo:
Git in Visual Studio and Azure DevOps is standard Git, github is the same.
So, that document also applies to azure devops, we just need to replace the github repo link to the azure devops repo link.
In this way, I have old Dashboard in the repo. Has anyone done this?
If you have old Dashboard in the azure devops repo, just clone the old json files to the local and update the json files and push it to the azure devops by git command line. Or you could modify the json files in the azure devops repo UI directly.
So, for the azure devops, you just need to make sure the Version control of your repo is git, and then you can handle azure repo like git.
I've recently been working on switching from On premise TFS to Azure DevOps, and trying to learn more about the different pipelines and I think I may have had my Build pipeline do too much.
Currently I have my Build Pipeline do
Get Source code from Repo
Run database scripts/deploy dacpacs
Copy files over to virtual machines that have web application set up already
Run unit/integration tests
Publish the test results
I repeat these steps closely multiple times, one for develop branch, one for current and previous release branch.
But if I want to take advantage of the Releases and Deployments areas what would that really get me?
It looks like it would be easier to say yes this code did make it out to this dev/beta environment.
I'm working with ColdFusion code that includes some .NET webservices within the repo, would I have to make an artifact that zips up the repo and then deploys it, or is there a better way to take advantage of the release pipeline?
It's not necessary to make an artifact that zips up the repo and then deploys it. There are several types of tools you might use in your application lifecycle process to produce or store artifacts. For example, you might use version control systems such as Git or TFVC to store your artifacts. You can configure Azure Pipelines to deploy artifacts from multiple sources. Check the following link for more details:
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops#sources
We have dozens of code repositories in Azure DevOps, and we're working on a major release strategy.
We have a stable development branch called develop, where code has been tested and peer-reviewed, with features approved by QA. All of our service repositories have a similar structure.
We want to "click a button" and branch from develop across all our repositories to a release candidate branch, that QA can regression test as a complete system... basically a "snapshot" of what we expect is ready for release. We would then build from this code base, release to our QA environment from the corresponding builds, and when certified, deploy to production, then smoke test and merge the release candidate branch into master, then master back into develop.
It doesn't seem like there's an easy way to manage multiple builds or releases in Azure DevOps though. Atlassian's Bamboo supported this concept of "meta builds" but I don't see a way to do this in Azure DevOps. I can't seem to even create a build that is not implicitly linked to a single repository.
How can I automate this and get this workflow working in Azure DevOps?
You can use a Build Task from the Marketplace that queue a new build: the first two found are Trigger Build Task and Build Chain.
You defined an overarching build that queues the single ones and does any additional work.