I would like to publish my VS extension like we publish the NuGet packages - to the Azure DevOps Package Management on every CI build.
But then, developers need to download and run it manually, because VS does not recognize it as a valid source of VS extensions.
Is it possible to configure VS so that it looks for packages somewhere else, in addition to the extension market place? Azure DevOps Package Management is ideal, but a shared directory on the company Intranet would work too.
Is it possible to configure VS so that it looks for packages somewhere
else, in addition to the extension market place?
For VS2017 and VS2019, we can share the extension by posting it to Private Gallery.
But for now, the host should be an Atom Feed or SharePoint site, it doesn't support Azure Devops Package Management(feeds in Artifacts?) or Shared Directory.
In addition:
Since the extension can't be installed in a running VS instance(It needs us to close VS instance to complete the installation), so actually we don't need to use the search option in Extensions and Updates within VS IDE if we're just trying to share the extension in the company.
Use a shared directory on the company Intranet, place the extensions(.vsix) in that, and members in same company Intranet can install that by double-click the xx.vsix file. (The function of auto-updating extension in VS is not available for this situation, but it meets the needs in most of the time. )
Related
We have some ASP.NET web application which used in 2 ways:
enterprise solution (msi-like installer)
cloud solution (use same installer)
Currently we use home-grown installer, but consider if we can replace it with something more convenient and suitable for CI/CD development cycle.
What technologies/products can be used? Currently I think about webdeploy, but not sure how it can be applied for enterprise setup...
This is quite a broad question, but I think it deserves an answer.
1. (partially) Open source solution
One way to configure CI cycle is to use Jenkins along with MS deployment functionality. This article shows how to quickly set up a job to integrate Jenkins with msdeploy tool.
Basically it configures a job to perform the deployment using Powershell:
msdeploy.exe -allowUntrusted=true -verb:sync -source:contentpath='D:\WS\ExampleProject' -dest:contentpath=F:\webfolder,computerName=exampleproject.example.com,Username='yourdomain\username',Password='password' -skip:objectName=dirPath,absolutePath="config" -skip:objectName=filePath,absolutePath="web.config"
It also tells that the executing user should be an administrator on target server, but this can be circumvented through proper configuration of Web Deployment Handler as indicated in this article.
One intermediary step that can be done before Jenkins integration (which I recommend) is to configure Web deployment. This allows to quickly check that deployment can be performed onto target server IIS using Visual Studio and any configured user that is allowed to deploy. It also allows to quickly see the difference between current code base (web pages, JS files, binaries) and target server deployed package.
2. Visual Studio 2017 DevOps solution
Microsoft recently released VS 2017 which contains a great support for DevOps which handles most the issues related to CI/CD. I cannot find a reference, but I remember that this feature is available for Enterprise version only. Also, the good news is that it is not tightened to Microsoft technologies.
A presentation related to the subject can be found here.
I think WebDeploy can be used without significant problems. From my experience with it:
backup limitation: can be done only at Web Site level, not Web application level
deployment time: is quite small - actual files copy + Web site backup (if configured) + application pool recycle.
Recently I saw a vendor offering customers who wanted on-premises deployments the same Docker image that they use for cloud deployments. Seemed like a good, clean, solution.
Another option is nuget packages - host your own repository. Then deploy with a tool like Octopus Deploy. I'm not terribly familiar with it, but both solutions look to be easy after an initial hump in setup.
I am currently using Visual Studio Team Services (was VS Online) to version control my projects. When I want to deploy my projects to my VPS I use the Visual Studio Publish that stores the files on my hard drive and then I use an FTP client to send the files to my VPS.
But now I am viewing the build and release functions in Visual Studio Team Services. But I don't completely understand it all.
Questions:
What is the purpose of the build?
I have created a new standard build definition using the Visual Studio template and used the Host agent pool.
When I run the build I can see that it creates a new version using the last commit as reference. But what has it done in the backend on the host agent?
And where are the files stored of this new created build? In the log I see Copy Files to: $(build.artifactstagingdirectory) but where is this?
What is the purpose of the release?
I have created a new release plan using the empty template because I don't have Azure, I use another company where I have a VPS running.
I then added 3 environments called Development, Staging and Production.
All of them using the Host agent, but I think here I need to adjust this because if I understand it I now can assign my VPS to my Production environment or not?
Does someone has done this using Visual Studio Team Services and a VPS that runs on Windows Server 2012?
Are there videos or docs available about this because its quite confusing what the correct steps are in deploying versions of web projects.
In general, "Build" focus on integrating and building your code changes and run some basic unit tests. And "Release" is used to deploy the output of "Build" to your environments so that you can run some future tests/verification and final deploy the output to a production environment for your customers to use. See this link for reference: What is the difference between build and release engineering, DevOps and site reliability engineering?
When you start a build without any source version specified, it will get the latest version of the code and then build the code. All the files are placed in the working folder of the build agent during the build process. $(build.artifactstagingdirectory) is a predefined variable that point to a path in the build agent work folder. We usually copy the build output to this path so that we can access to output easily in the following tasks. For example, use "Publish Artifact" task to publish the output files in $(build.artifactstagingdirectory) folder to the server or a file share, and then the team members can get this build from server or file share.
In the release, you can link a release to the build definition. When the release starts, it will get the latest artifacts of the build and deploy to your environment.
The agent is a machine used to execute the tasks in build/release definition. Hosted agent is managed by Azure and you can also deploy your own build agent. So you don't need to change the agent settings for "Production" environment if your VPS can be accessed by the Hosted agent. Since you are using FTP to upload files to your VPS previously, you can still use this method to publish the files by adding a FTP Uploader task in release definition.
For more information, refer to Build and Release Management for details.
What are the best practices and options for expanding to a small team ?
I am the only user of Visual Studio 2012 in my small company. I am using Visual Studio Online for Source Control (as I understand it, this exposes Microsoft Visual Studio Team Foundation Server Version Version 14.0.12345.23456 as a "service" (i.e. this is the cloud...there is no on-premise TFS installed). Currently, I am using a LOCAL workspace (the default) and TFVC (not GIT).
My development server runs IIS 7.5 on Win2008 R2. I logon locally to this dev server and launch VStudio 2012 Professional as an administrator. Project source code is on the local harddrive (e.g. d:\projects\projectA, etc.). I can interactively debug my web application projects and sit on a breakpoint without "disturbing" any other user or developer.
I work remotely so I use a mobile VPN with SSL to connect via Remote Desktop to the above development server (only 2 concurrent connections are supported now).
Some specific questions:
Can another person(s) somehow "share" the above environment?
How can developer2 and dev3 work concurrently on same project(s) as me?
Can I simply add dev2 and dev3 logons to the admin group on the dev server?
Would changing the TFS setting from LOCAL workspace to SERVER workspace enable team development (i.e. prevent checkout if already checked out, etc.)
If "sharing" the above environment is possible, what would the ideal arrangement look like (e.g. each developer has own server, own Vstudio license, etc.)?
Usually, every developer in a team has their own development machine. You create a team project in Visual Studio Online, and check in your project to this team project. When you want to dev2 and dev3 to work on this project, you can add dev2 and dev3 in the team project (Visual Studio Online provides 5 free licenses), so they can access this team project and get the project to their development machine.
Team Foundation Version Control is a centralized version control system. Typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Every time your team checks in their work into Visual Studio Online, you can easily audit changes and identify which user checked in a changeset.
Regarding Workspace, please check the definitions below:
•Server workspaces: Before making changes, team members publicly check
out files. Most operations require developers to be connected to the
server. (In the past teams blocked more than one person from checking
out, but this is now less common.) This system facilitates locking
work flows.
•Local workspaces: Each team member takes a copy of the
latest version of the codebase with them and works offline as needed.
Developers check in their changes and resolve conflicts as necessary.
Usually, local workspace is recommended.
More information of TFVC, you can refer to https://msdn.microsoft.com/en-us/library/ms181237%28v=vs.140%29.aspx
What are the options for deploying a web-application that is built daily using Visual Studio Online (and hosted controller) and its new build definitions to an on-premises IIS behind a firewall?
If opening up the firewall, would it be possible to add some kind of WebDeploy-build step to the Visual Studio Online build? Haven't seen any WebDeploy build steps for now though...
...or could we write a PowerShell script running daily on the IIS-server that fetches the output of the daily build from Visual Studio Online? If that's possible, how can those files be accessed?
...or could something like OctopusDeploy help out here?
would like to refrain from having to set up an on-premises build controller.
VSO Agents are lightweight and easy to setup if you have a server available. Octopus Deploy integrates nicely most on premise scenarios.
That said, if you still want to keep hosted builds, Octopus would still work.
Create a VSO build definition and include OctoPack.
Pick a hosted Nuget Server, presumably with a private repo subscription. A couple of options are MyGet and Artifactory.
In "MSBuild Arguements" include the parameters.
/p:RunOctoPack=true
/p:OctoPackPublishPackageToHttp=http://nugetrepoofyourchoice.com/nuget/packages
/p:OctoPackPublishApiKey=$(NugetAPI)
/p:OctoPackPackageVersion=$(Build.BuildNumber)
"NugetAPI" is actually a user defined variable (name of your choice) that references a Secret build variable. You will get this API Key from your Nuget Repo vendor.
On premise, in your Octopus installation, you would define your hosted Nuget feed as an external feed.
In your deployment project, it would pull the Nuget package from your hosted repo.
VSO pushes to hosted Nuget feed and Octopus pulls from the hosted Nuget feed.
Octopus deploy would work for this in a couple of ways.
1) Install a tentacle on the IIS server (either polling or listening will work depending on where you install octopus manager)
or
2) Install the main octopus deploy on a machine that has WebDeploy access to your IIS server, and use the custom library MS Deploy script
Getting the package to the main octopus deploy machine could be a bit tricky. Easiest way would be setting up a MyGet server and have the octopus server check it periodically, that way you don't need to open up firewalls to the public.
These feature are coming for VSO and were announced at Build. You will be able to deploy on-premises without needing to open a firewall port using agents.
While this is still in the works you can use Release Management for Visual Studio 2015 to pull the bits from VSO and deploy locally.
The product I’m trying to create a package out of is a Web Application and a Database Project. This Package needs to be deployed to multiple IIS Web Sites which individually has their own application pool and bindings. In the end I would want the package to be built by a TFS Build Server into a .zip file which via msdeploy.exe somehow can be deployed to these web sites by settings the web site, application pool, binding and destination database in deploy time. It should create if items does not exists and update if they do.
I’ve been researching quite a lot on Web Deploy 3.0. Most of the stuff I find on the internet via google is about defining the package and publishing from within Visual Studio which is not exactly what I want because I want to be able to have control over the settings at deploy time.
So far I can create a package relatively simple via the Publish dialog in Visual Studio 2013. I can even add my SSDT project dacpac file to the package using the “Update Database” checkbox in the Publish window. But I think a lot of things happen behind the covers which doesn’t seem logic how to do manually.
Ultimately the questions I have right now which I hope someone can help me with is:
How do I define dbdacfx settings in deploy time when deploying a
package? (Ie. Target sql server, database, username and password.) Or
can I parametrize these settings somehow into a parameter.xml file?
Can I use the publish profile xml file from my SSDT project?
How do I make my package create a new web site if it does not exists?
I can only find information about creating applications under already
existing sites.
When and if I create a web site via the package, how do I define the
associated application pool? Like creating it if it doesn’t exist or
update it if the target framework is incorrect?
I’ve read about providers. For instance appPoolConfig provider but
how to utilize this at deploy time isn’t very clear to me – can
anyone elaborate or perhaps point to a source explaining it?
Is there any good books covering this area or perhaps even a better
alternative?