Is there a way to automate storing code updates to GitHub after a developer publishes a new version of code from Visual Studio (2017 or 2019)?
Or is there a way to automate storing code updates to any code repository?
We also currently use VisualSVN, but are open to other repository software packages if they solve this problem for us.
We publish web projects and console apps to on-prem servers, so my understanding is that GitHub Actions won't work for us (yet).
If you are pushing to an on-premise Git repository hosting server, you can add to that remote repository a post-receive hook.
Said hook can in turn analyze what just got pushed and push it in turn to GitHub.
See git-post-receive-hook-push-to-mirrors as an example of such hook.
Related
We have Artifactory and Xray for our developers and we have Azure DevOps pipelines integrated with these tools where the builds are scanned for each pipeline execution.
But when developers are doing local builds from their development workstations they also need to be scanned before merging to the repos in ADO.
So we are looking for some possibility where the developers are able to connect to Xray from their IDE client itself.
They are using IDEs like, Visual Studio and Visual Studio Code
need to Run the local builds of - NuGet, Maven, Gradle, Android, IOS, Nodes..
Can anyone suggest how this can be achieved from IDEs or CLIs like (jFrog CLI, or git bash, etc...)
You can use the JFrog VS Code Extension which allows you to scan project dependencies using JFrog Xray in VS Code.
It allows developers to view panels displaying vulnerability information about the components and their dependencies directly in their VS Code IDE. The extension also allows developers to track the status of the code while it is being built, tested and scanned on the CI server.
The requirements on the following page state that you need to install Visual Studio with Xamarin on your local TFS server to setup Xamarin CI builds:
https://developer.xamarin.com/guides/cross-platform/ci/intro_to_ci/
topography of the CI
This is a real pain. We have lots of developers that rely on our local TFS server, most of whom don't do any Xamarin development. As such, any changes are heavily scrutinized. This often leads to us not installing the latest VS/Xamarin releases, as it's considered too risky for this vital bit of infrastructure.
We could have a Windows build machine with VS and Xamarin installed, that is connected to a Mac build machine. We'd be free to update the Windows and Mac build machines regularly, without the fear of compromising the TFS server. Is this possible? If not, why not?
Thanks in advance.
That diagram can't be right. There is no reason why you'd need VS or Xamarin installed on your TFS app tier.
I think it's showing a simplified configuration where the Windows build agent is installed alongside the app tier. That is a supported setup but is never, ever recommended by anyone, for exactly the reasons why you don't want to do it.
The diagram is simplified. You don't need to install anything on your TFS server. What you do instead is to install a Build Agent on a separate machine or virtual machine.
The installation details for the TFS 2017 / VSTS build agent v2 can be found in the official visual studio documentation.
The procedure is similar for both TFS and VSTS, where you generate an access token in TFS/VSTS, then simply enter the url for the TFS/VSTS instance when running the build agent install script, along with the access token.
There are build agents for Windows, Linux and macOS, so it is up to you how you configure how iOS builds are made.
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
I just read an extremely interesting article that apparently as of this past Visual Studio 2012 update, it now has official Git support built in.
My question is, what does that mean exactly? Does this mean that TFS servers can now host Git repositories? Or, does Visual Studio use something like git-tfs behind the scenes to use regular TFS repositories with a Git bridge? Or does this apply to TFS servers at all? Also is using Git outside of Visual Studio which is hosted on TFS plain ol' vanilla git, or is it like the git-tfs bridge?
Also, is there any documentation yet about converting a TFS repository to a Git repository with this support?
Visual Studio Online hosts git repositories and provide integration to TFS work item tracking and builds. We store this information in a proper git repository - it's not a transparent git-tf bridge. Instead, we store git references and objects, although we store them in a SQL Server (SQL Azure) instead of a traditional on-disk git repository format. We do this to integrate with the existing TFS manageability and Team Foundation Service scaling.
Team Foundation Server, the on-premises product that resides in your data center, from TFS 2013 supports git repository hosting. Many features arrive on the hosted Visual Studio Online before arriving in the on-premises product.
Similarly, the Visual Studio integration is a proper git client - again, it's not git-tf. It uses the libgit2 and libgit2sharp projects to provide repository access to a local git repository, as well as network access to provide pushing and pulling to any git hosting service that speaks HTTP. (The SSH transport is not currently supported.) This means that you can push and pull to Bitbucket or GitHub, for example, you need not talk to Team Foundation Server.