I am working with Azure pipelines where the microservice has a dependency which has different versions.(Example: abc-1.0.1, abc-1.0.2) How should I store those dependency in Azure Devops
I came across The Universal Package task, which is currently not supported with Azure Devops Server. How should be the versioning of packages(created by gradle build) maintained while working with Azure Devops Server.
As currently different versions of build/jar is required by microservices. In order to maintain those versions, names, what is the best way in Azure Devops. (Note: As mentioned we are working with Azure Devops Server, not Azure Devops Services)
The Universal Package task is not totally unsupported on Azure DevOps Server. It can be available on TFS 2018, Azure DevOps Server 2019 and Azure DevOps Server 2020.
So, if the version of your Azure DevOps Server (TFS) is TFS 2018 or later, you can use this task in your pipeline as normal.
If your TFS version is lower than TFS 2018 and does not support using the Universal Package task, you can try to call the Azure CLI "az artifacts universal" in the pipeline to publish and download the Universal Packages.
az artifacts universal publish: to publish the Universal Packages to the Artifacts feed.
az artifacts universal download: to download the Universal Packages from the Artifacts feed.
Related
We normally use on-premises Azure DevOps Server to maange our build pipelines, using YML files. We have build agents running on one or more build servers.
A specific piece of R&D would be made far easier if we could install VS and a build-agent on a standalone box which is not linked to the Azure DevOps server, and manually 'run an YML build' against the build agent locally.
We don't have access to DevOps server from this machine and the alternative is rescripting an alternative to our YML in Powerscript or similar.
Is there any realistic way to do this?
Is it possible to manually run a build on a local Azure build agent without a DevOps server?
I am afraid there is no such way to manually run a build on a local Azure build agent without a DevOps server.
That's because azure devops services/server is equivalent to an interpreter and trigger. Agent itself is not a program that can be executed independently like MSBuild.exe, it does not have the ability to parse YAML grammar, it can only execute the parsed command passed by the server.
I totally understand your needs and approve of it, so I recommend you add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions：
Can any one suggest a flow how to publish Azure Devops server 2019 maven artifacts (exposes API) to Maven central for a more global access?
update:
let me rephrase my issue.
my team uses on-premise Azure Devops to develop and host android packages used as API for other applications.
when the API version is stable we want to publish the API packages (in the on-premise artifacts) to Maven central, i wish to use the release management so i could use the approve mechanism
Azure Artifacts, part of Azure DevOps, offers the ability to host and share Maven, npm, NuGet, and Python package feeds within your organization.
If you want to host the packages on Maven central instead of Azure Artifacts. You would check how to upload packages to Maven central on Maven side:
https://maven.apache.org/repository/guide-central-repository-upload.html
If your goal is only sharing packages publicly, you may try Azure DevOps Service (https://dev.azure.com), which support sharing your packages publicly. This feature currently only support Azure DevOps Service.
We are using Azure Devops server to host our GIT projects. We also use Azure Devops Server for our development process. For historical reasons we have our repositories in one teams project and work with our tasks in another. It has never been any problems to be connected to those two different teams project until the release of Visual Studio 16.7. When I now connect to my GIT project I can't see the teams project where all my tasks are.
Is there anyone else that has a solution for this?
Please try the following items:
Go to web portal, to see whether you can see the team project where all your tasks are.
If you can see the team project in web portal, check whether you use the same account to access the server in VS.
Close all Visual Studio instances, delete %LOCALAPPDATA%\.IdentityService.
Clear Azure Devops server caches %LOCALAPPDATA%\Microsoft\Team Foundation\x.0\Cache.
Re-launch the VS and try to connect to server again.
we uses on-premise tfs 2008 for source safe and build engine. The build script is heavily customized with msbuild scripts. Developers uses active directory to authenticate then queue a build.
We look around to go to Visual Studio Online, question
- the big concern is the build script, we don't really want to rewrite it, is it possible to use the current MSBuild project in the VSO build process?
- for authentication, how to integrate with the on-premise AD with the VSO? how to migrate the existing security project settings to the VSO?
Ok, so the answers to all of your questions is maybe 😊.
You can continue to use your on-premises build server with VSO. If you upgrade your agents to TF Build 2010 or 2013 servers you can plug them into VSO and build in the same way.
You may be able to use the cloud build agents if you don't need custom things installed on the build agents to compile. Probably best to stick with local agents for now.
For AD you can configure an Azure Active Directory (AAD) and wire it up to VSO. There is then a connector to sync your local AD with AAD (very easy) and enable single signe-on. There are fiddly bits but mostly strait forward.
http://nakedalm.com/use-corporate-identities-existing-vso-accounts/
I enabled it for my account but without the local AD sync as I don't have one.
I have a few customer that are on VSO and sync their local AD with AAD and are very happy.
My team uses Visual Studio Online ("VSO") to manage our ALM.
We already have a push-button build-process in place to build code from our local Git repo (remotely) and deploy it to a Microsoft Azure Website on Azure.
In addition to this we want a local, development-testing environment built and deployed with a push of a button.
What is the best way to integrate an automated, on-premises development-testing deployment into our development pipeline from within VSO's ALM ecosystem?
[We do also own TFS 2012 -- is there a way to leverage it from VSO to drive an on-premises build deployment from our VSO git repo?]
To deploy builds on-premise, I installed an on-premise build server and used it as the default build controller in my build definition.
When installing the build server select your Visual Studio Online url to point the build server to your team project collection.
I used the instructions here
http://myalmblog.com/2014/04/configuring-on-premises-build-server-for-visual-studio-online/
(normal issues when installing a build server remember to copy over your MSbuild folder from a machine with Visual Studio already installed etc...)
I know it's been a while since the question was asked, but this guy did it with an extension to be added to your VSTS account to deploy directly to an on-premise IIS. I'm going to check this solution today but I'm pretty sure it will work.
https://blogs.msdn.microsoft.com/monub/2016/01/20/visual-studio-team-services-release-management-iis-web-deployment-vnext/
UPDATE
Better yet, MSDN released a complete doc for deploying an asp.net app on IIS
https://www.visualstudio.com/en-us/docs/release/examples/other-servers/net-to-vm