I'm using SQL 2016 and am creating SSIS packages. Due to the environment, the SSIS packages must use the package deployment model and not the project deployment model. Integration Service Catalogs will not be installed.
This link indicates using the legacy package deployment model, SSIS packages may be stored in the MSDB.
https://learn.microsoft.com/en-us/sql/integration-services/packages/deploy-integration-services-ssis-projects-and-packages?view=sql-server-ver15
I've googled for instructions on how to store legacy package model SSIS packages to the MSDB and can't seem to find any instructions.
Create deployment utility
https://learn.microsoft.com/en-us/sql/integration-services/packages/legacy-package-deployment-ssis?view=sql-server-ver15#create-a-deployment-utility
Then deploy with deployment utility (.SSISDeploymentManifest)
https://learn.microsoft.com/en-us/sql/integration-services/packages/legacy-package-deployment-ssis?view=sql-server-ver15#deploy-packages-by-using-the-deployment-utility
Related
I have a build that seems to behave differently whether I send it to a hosted agent in the cloud or to an on-premise agent. The solution being built has projects exclusively using <PackageReference>, and the solution is being built using the new-ish msbuild /restore function. The specific way in which it behaves differently is that on the on-premise agent, the NuGet restore generates a bunch of warnings like this:
##[warning]IQ.Core.Update\6.0.0\IQ.Core.Update.Services\IQ.Core.Update.Services.csproj(0,0): Warning NU1603: IQ.Enterprise.Activation.Model 6.0.8 depends on IQ.Framework (>= 6.8.0) but IQ.Framework 6.8.0 was not found. An approximate best match of IQ.Framework 6.8.1 was resolved.
There are in fact much newer versions of IQ.Framework available from our internal package server.
Running the same build, the cloud agent does not generate these warnings. Is it possible that the cloud agents come pre-configured with a NuGet.config that overrides the default behaviour by setting "dependencyversion" to "Highest"? Or is there perhaps something different on the hosted agents that causes warning 1603 to be suppressed??
A previous incarnation of this build running on TeamCity also did not log these types of warnings, and I'm pretty sure our TeamCity agents didn't have any special NuGet configuration.
I am worried about whether the builds on the on-premise agent might actually be functionally different than the cloud agent, and the earlier TeamCity builds, if it's building against different versions of referenced packages.
... depends on IQ.Framework (>= 6.8.0) but IQ.Framework 6.8.0 was not
found. An approximate best match of IQ.Framework 6.8.1 was resolved.
This warning always occurs when restore process can't find one specific version of referenced package. And it indicates that the IQ.Enterprise.Activation.Model-6.0.8 in on-premise agent's cache has something like these in its xx.nuspec file:
<dependencies>
<dependency id="IQ.Framework" version="6.8.0" />
</dependencies>
Azure DevOps hosted agents NuGet dependency version behaviour
After the long discussion with Jonathan we've confirmed that this strange behavior resulted from the different content of the IQ.Enterprise.Activation.Model 6.0.8 in both agents. Though they're same version 6.0.8, their xx.nuspec file actually have different dependencies. In local agent it should be <dependency id="IQ.Framework" version="6.8.0" /> while in cloud agent it's apparently not 6.8.0. So this warning occurs in local machine but not occurs when using cloud agent.(The 6.8.0 is not available for both two agents)
Is it possible to include an SSIS package file (.dtsx) as part of an EF Core 2.2 Migration, such that the migration installs the package on the target server?
In a Migration, you can include arbitrary SQL scripts with MigrationBuilder.Sql(). And there's a set of stored procedures you can use to deploy an SSIS project or individual packages to the SSIS catalog.
This is one way to handle SQL Server artifacts that aren't directly supported by EF migrations. However, the need to deploy things other than your database schema is a indication that you should strongly consider using SQL Server Data Tools (which has first-class support for SSIS) to manage your SQL Server DevOps, instead of EF Migrations.
I created a sample project using VS2017 "ASP.NET Core Web Application" with Angular.
Then in VSTS I built using Build Template: ASP.NET Core (Build ASP.NET Core Web Application targeting .NET Core). This built successfully and in the artifact section kept the build in a .zip file.
I would like to deploy it to a scale set. So for the Release section I used "Azure Virtual Machine Scale Set Deployment" template. While filling it out there is a field "Deployment Script field" which is mandatory. Not sure what this script is used for and how do i configure in it and where to source the script from.
TL;DR:
This script deploys the content of your deployment package on the virtual machine that you're preparing. In the case of an Angular ASP.NET Core app, this means that you will have to install IIS, the .NET Core Windows Server Hosting Bundle and copy your app to IIS.
Extra info
The Azure Virtual Machine Scale Set Deployment template creates an environment with two tasks:
Build immutable machine image
Azure VMSS: update with immutable machine image
Both tasks have a bunch of fields that need to be configured. Release Management allows you to link important fields to your process. This means that these settings are all grouped under the environment and can be easily set without going through the tasks.
If you look at the following screenshot you'll see that beneath the selected Deployment script field there is a line: This field is linked to 1 setting in 'Build immutable machine image'.
If you look at the documentation for the Build immutable machine image tasks you see the following for the Deployment script:
Deployment Script: Specify the relative path to the PowerShell script (for Windows) or shell script (for Linux) that deploys the package. This script should be within the deployment package path selected above. For example, Deploy/ubuntu/deployNodejsApp.sh. The script may need to install Curl, Node.js, NGINX, and PM2; copy the application; and then configure NGINX and PM2 to run the application.
So this is the script that will automatically deploy your application to a VM. In the case of an Angular ASP.NET Core app, this means that you will have to install IIS, install the NET Core Windows Server Hosting bundle and copy your app to IIS.
I would encourage you to first create an empty Windows Server 2016 VM and experiment with creating a script that prepares the VM and installs your app. Once that's done, you can reuse this script in the Build Image task in VSTS to automate VM and image creation and use that image for your Scale Set.
UPDATE
Your VSTS Build produces an artifact. In your scenario, you are already publishing the zip file with your web application. You can configure the Publish Build Artifacts task to also publish any deployment scripts you want to use during your release. These scripts should be stored in version control. The whole artifact, including your zip file and any deployment scripts you add, is used as input to your Release Definition. The zip file contains your web app as a Web Deploy package that you need to deploy to IIS. This piece of documentation explains how to install Web Deploy and use it to deploy your app.
We are currently using web deploy for creating packages for our .net web applications. It got some pros and cons. Now we are going to use nuget for dependency management but given the ease of packaging in nuget .. i am debating on should i still use web deploy + remote service or try to use nuget to bundle my web application and use powershell or something like octupus to deploy ??
For my web deploy becomes little complex when even try to do simple things like include , exlcude , gac or registry or iis config ( which again not very flexible ).
But on the other hand it comes with remote service and all i need to do is through the package to the service and i am done..
Please give your inputs on this comparison.
-raj
NuGet is a dependency manager, and as such is appropriate for use at development/build, not deployment time. From a deployment perspective, it doesn't offer you any more than what a zip file does... except all the overhead of trying to fit NuGet in the process.
Take a look at Inedo's BuildMaster. It can take care of the process from source control through production deployment. There's also a free version that will most certainly handle your requirements, and it also has a module to manage your configuration files so you don't need to worry about doing transforms.
(disclaimer: I work for Inedo)
I am setting up a system that uses NuGet and Webdeploy.
NuGet is used as the repository format, so the build system publishes NuGet packaged artifacts.
The Deployment systemn uses NuGet to get the RIGHT packaged artifact from the NuGet repository.
The build artififact happens to be WebDeploy for easy installation.
I am still working out if I am going to use puppet, chef or octupus to orchastrate the deployment.
How do you handle the deployment of a LightSwitch application into a production environment?
i.e. the LS application has been developed, but it now needs to be installed first into Test, and then into Live.
We don't want to use the "manual" approach, i.e. use the Visual Studio Build / Publish option, rather we want to automate the deployment.
My feeling is that deployment is one of the real weak points of LightSwitch. If you are using the very simple deployment model that is build into the product, and you're doing everything within a Windows domain, the publishing wizard can do everything. But if you're deviating from the model at all LightSwitch will fight you. I'd really like to see an "advanced" deployment option that provided some configurability.
Here's how I solved the problem you're having with LightSwitch applications that are targeting web deployment:
At the beginning of the project, deploy once to each target environment using the publish wizard. This is the easiest way to get the database set up.
As new builds are deployed, use the publish wizard to deploy to a deployment package to a standard location on the local development machine.
The deployment package is just a zip file, so you can open it an drill down to where the actual binary release is. I use a powershell script to copy the binary files out of the the deployment package and in to a local SVN working directory. Note that you must not copy web.config file during this step.
Check the unpacked binary files into SVN and use SVN to manage the deployment.
Manage schema changes with SQL scripts.