Forgive me for asking a stupid question. I am from IT Infrastructure background & have been asked to create CI/CD pipelines based on my recent learnings on DevOps.
We have couple of applications whose source code is currently in TFS 2013 & those apps are written in ASP.NET C# language. Now, requirement is to migrate the source code from TFS to Azure Repos (Azure DevOps services) & further create a CI/CD pipeline.
Now for demo purposes, customer is asking us to do the deployment (i.e. Release pipeline) on a test server which is a plain windows 2012 OS without any SQL & IIS for both of these applications. Is that possible & how could we achieve the results to confirm release pipeline is funcioning properly?
In my opinion, it wont work as there is no application infra/configuration done for those applications on that plain test server. I guess we actually need a ready dev/stage environment which is replica of production to do the testing of release pipeline for those applications. Am I correct?
Just need expert advise for confirmation so I communicate the same to customer.
Azure DevOps Pipelines use an agent to perform the deployments. You can run the agent entirely in the cloud when deploying to Azure resources. You can also install an agent locally. Follow this link and scroll down to read about self-hosted agents. This is how you can deploy to your test instance from the pipeline.
Now, what you deploy there may require additional software be installed. You say it's an application in C#. Cool. Now, what's it do? Is it a windows program? Then just having the server there, with an agent installed, is all you need. Is it a web program? Then, yeah, it's going to need an IIS (or whatever) instance available somewhere to deploy to. Is it a database program? Then, yeah, it's going to need a database instance to deploy to. There's nothing magical about having a VM or a machine somewhere. All the same rules have to apply. There has to be an OS, drives, memory, and yes, supporting services depending on the needs of the application.
However, using a local machine instead of a hosted one, that works fine. Just follow the instructions in the link above.
Related
Asking for an opinion or direction on the current problem.
We are using bitbucket pipeline to deploy ci/cd web applications to Azure. Now what is remaining - the database, also being hosted on Azure.
From my research - everything on SQL Database Projects deployments usually utilizes Azure DevOps pipelines (connects to github repo, allows plural environments, has a built-in SqlAgent allows deploy SQL db to the target server via dacpac file. It allows CI with every check-in, every time you push changes. Nice!
But what if can not (for some reason) use Azure DevOps and have to utilize Bitbucket pipelines instead. is that possible? how? via scripting? a tool? to call in the command line? Any help - highly appreciated.
It's true that in Azure DevOps it is easier to deploy (Azure) SQL Database, as Azure DevOps offers many tasks (including 3rd party custom tasks you can find in Microsoft MarketPlace).
However, no matter what tool will you use, you should be able to do the same, knowing the concept of deployment of a specific service.
I don't know BitBucket very well, but I bet the product has the capability to execute some commands, including PowerShell commands as well. If so, you must do 2 steps in your pipeline to publish Azure SQL database:
1) Create server and (empty) database - perhaps BitBucket offers some task for creating services in Azure (from ARM template or other way). If not - you can always use CLI or PowerShell to do so. More info: az cli server
2) Deploy the database or changes to it. This step is always to compare DACPAC file (which is compiled version of SQL Server database project) to target database on the server. The result is T-SQL (differential) script which must be executed against the target database. There is only one way to do so - sqlpackage.exe - tool provided by Microsoft. You can find the whole documentation here and plenty of examples on how to use it on the Internet.
Let me know if that helps.
I'm using azure devops pipeline to build my IIS application and deploy via release management to several different servers, and it works great. My issue though is that one of the servers I need to deploy to will always be offline, so I need to set up some sort of offline installer for that deployment. Is there a way to do this using the build and release management I already have that I'm not seeing?
Azure Pipelines assumes that the server is always available. Best I can think of is to generate some kind of drop on a fileshare and then add a Manual Intervention Task to pause the pipeline and allow you to do your thing.
There is no air-gapped agent nor a way to run part of your pipeline on another system and import the results.
I am migrating XAML Builds to Azure Devops. Goal is to remove the dedicated Build Staging server to cut costs.
Following is the process:
1) Build ASP.NET Web Application.
2) Copy configs, assemblies, WebPackage from Build output to various folders in UNC share which will be later picked up by a Release Pipeline Job.
Since Microsoft Hosted Agents dont allow usage of UNC share, I wanted to use Self Hosted Agent.
Question:
Can I use a Self Hosted Agent without the necessity of a dedicated server to hold the Build Output in Image or Container which can then be copied to the UNC Share? I am new to Devops and hence the articles on MS confused me if I need a dedicated server or not.
Tried to set up a Self Hosted Agent pool, but the steps suggest that I require a machine where the Self Hosted Agent need to be setup. If this is the case then it means I will be requiring a dedicated machine like in XAML process. Am I blabbering? Please excuse if yes :-)
Expected Result: Run a Build Pipeline with Self Hosted Agents on Cloud without the requirement of a Dedicated Server.
UNC Shares or not, the "self hosted agent" is an agent you install on your own server, there can be multiple reasons for that, for example accessing an sql server for testing that is on your own local network, to perform tests against during builds.
If you are trying to reduce costs, a self-hosted agent can be benefitial if you already have server hardware it can run on. If not, you might aswell just use a hosted build agent, anything build on that can be published directly azure devops or other places though various build tasks.
...Since Microsoft Hosted Agents dont allow usage of UNC share...
This is not a problem, there is no reason for you to use UNC shares.
You don't need to access UNC shares to store artifacts for later consumption; use the Publish Artifacts build activity. That will store your build outputs internally and make them available to downstream releases.
I'm trying to use TFS 2015.1 on premise to build a CI pipeline for our dev & uat. I've created a vNext CI build, which builds fine. But when I want to add a deploy step for on prem IIS server, I only then see Azure Web Deployment options.
Ideally I wanted to add a step which uses the existing deploy (MS Deploy) profiles, which I'm able to use from VS2015 directly, using 'Publish'. However I see no option to do so.
How can I deploy the latest build to internal dev servers (not Azure)? I would like to use the MS Deploy option, unless there's a better way of doing it?
The fact that their is no option to starts to make me think there's probably a different way to accomplish it!
Thanks.
If you're able to upgrade to TFS 2015.2, web-based Release Management came out with it that works similarly to Build vNext with flexible and open-source tasks. You can also customize tasks.
Here's a link for IIS Web App Deployment from the vso-agent-task's GitHub repo where Microsoft stores updated versions of their tasks that you can download for web-based Build and Release Management.
I'll be publishing a blog about web-based RM with TFS 2015 Update 2 or VSTS on my website in the next few weeks. To give you an idea though, the starting point (for a web application) is a folder in your web project called WebDeploy (no significance - any name will do) that contains a PowerShell DSC script that configures the server, deploys the web files and then replaces any tokenised configs. To give you an idea see this post about how to use DSC to configure servers. (Only covers part of the final script though!) The next steps are:
In the build hub create a Website artifact - containing your web files and DSC script.
In the release hub for an environment use a Windows Machine File Copy task to deploy the artifact to a temp folder on the target node.
Then use a PowerShell on Target Machines task to execute the DSC script. After configuring the server the script copies the web files to their proper location, sorts out config using xReleaseManagement and cleans up the WebDeploy folder.
See this article for general details of the route I'm taking, but watch out as it has some errors eg the firewall instructions are incomplete (file and print sharing through the firewall needs to be enabled).
I can thoroughly recommend the PowerShell DSC route - I've had a few glitches but on the whole it feels very productive and the right way to be going.
We have Continuous Integration setup through TFS 2012.
Requirement:
Wanted the release build to be deployed on mulitple servers as a part of the CI. We need to do a xCopy of the files onto the server folders.
On TFS with Azure there seems to be a facility to publish it directly onto the server (http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-tfs/)
There-in it uses 'AzureContinuousDeployment.11.xaml' as the Build Process Template.
Wanted to check if anybody has tried similar publishing for custom/local servers, maybe using Custom deployment template, etc.
You likely want to create Standard Environments for Automated Deployment and Testing which you can do out of the box with TFS 2010. TFS 2012 and TFS 2013.
You use the "Lab Centre" which is part of the Microsoft Test Manager product to configure Environments that consist of one or more target machines.
You then use the Lab Default Template to push a build output to the target servers and execute a script to complete the install. You can even have your Integration and UI tests executed as part of the same actions.
If you are looking for more integrated Release Management with Team Foundation Server then you should look to Octopus Deploy as a good way to go all the way to production.
We use it with many of our customers and it works a treat...
From my understanding TFS 2012 ships with a Lab Deployment template. You configure the lab definitions of which servers are involved and then configure the deployments to those servers. Also used for hooking Test Manager in to run unit tests in the lab.