It's there any way that i can specify a schema name that i don't want to be deployed with Octopus Deploy? I have a Visual Studio database project that has a schema generated automatically (with tables and stored procedures). I don't want this to be deployed.
I can't delete it directly from project because it verifies the dependencies at build time.
There's nothing specific to Octopus to do this however this stack overflow post covers the options.
If you're using a custom script step or a community step template to deploy your dacpac, you can provide additional parameters to control what is deployed.
Related
I have visual studio solution with 2 web projects. The source is in VSTS and the apps are hosted in Azure. I have build and release management setup to automatically deploy to Azure.
So every time I check in something, 2 releases are triggered, one for each web project. Is there any way I can separate the two? The web project should only trigger for a check in on that folder and the api trigger for a check in on that folder?
You just need to change Path filters for specific path of each web project path. More information, you can refer to Build definition triggers.
I'm trying to create web deploy packages through visual studio team services.
Currently, I have created a web deploy publish profile in Visual Studio. I use MSBuild in Visual Studio Team Services to build the solution and create a web deploy package. I then zip the package and save it to a shared location. However, the issue with this approach is that it does not provide me a way have a same build for different environments. Let us say, I created a web deploy package for DEV environment. Then when I have to deploy the build to SIT environment, I would need to build the solution again and create a package. This way I would have different builds for different environments. I would like to have the same build get promoted to different environment for better traceability and maintenance.
One way I feel I can achieve this is to have a separate build definition for just building the application and save the DLLs to a shared location. I can then have a separate build definition which takes the build from shared location and create a web deploy package from the build. How can I achieve that on VSTS?
Other way possible is creating a label when any deployment happens one environment, say Dev environment. To do the deployment in SIT I can use the source code with same label and then use MSBuild to create a web deployment package. Is there any way to achieve this through VSTS with/ without creating a separate build definition of each environment?
Any other suggestions than above?
You can use VSTS Release Management to deploy your deployment package to different environment and use "Tokenizer" task in Release Management Utility tasks to update the config file in the package base on the variable for different environment configurations.
And you can also try with Web Deploy Parameterization.
We use Hedgehog Team Development for Sitecore to manage content items and also want to use it for content deployment.
I am trying to create a TDS build configuration that should deploy TDS items to a remote dev server. Dev server isn’t on my local so I don’t know what I should mention in “Sitecore Deploy Folder” field.
What I am trying to achieve is when any developer / TeamCity builds the TDS project in dev configuration the TDS items should be deployed to the dev site. I can’t create this configuration from the dev server as we don’t have visual studio on the dev server.
I even tried putting the path from the server (this path doesn’t exist on my local from where I am try to set the configuration) but that doesn’t work.
Any directions on this would be much appreciated.
Thanks.
On the Build tab of your TDS project, there are two fields.
Sitecore Web Url This is what TDS will use to connect to the server component to deploy your items.
Sitecore Deploy Folder This is used for two purposes, one to install the aforementioned server component ("connector") and to deploy the output of your web project.
For deployment to a remote server, the Sitecore Deploy Folder needs to be a UNC path to the web root on the server (e.g. \\devserver\share\path-to-webroot), and whatever identity is running the deploy needs write permissions on that share.
I believe TDS only uses this path for deploying the "connector", which consists of the _DEV folder with the web service endpoint and some libraries that are placed into Website\bin.
If you are choosing to use the Deploy feature of TDS for CI, ideally you would deploy the "connector" manually the first time and although there is no use in setting the Sitecore Deployment Folder anymore TDS would not deploy with it blank. Your best bet is to setup a share on a server and use the share path for that setting (i.e. \myserver\share).
As a side note, check out the TDS package installer that comes with the app under C:\Program Files (x86)\Hedgehog Development\Team Development for Sitecore (VS2013). It is possible to set the TDS projects to generate *.update packages for code and content and automate their deployment or deploy them manually - just another way of implementing the CI.
I am using TeamCity as build for Sitecore and TDS deployments. Have a few different configurations depending on packaging needs. (update packages vs. webdeploy, etc).
Our typical approach to this is to create the MSBuild XML file for the configuration directly, which allows me to control the CI builds and deployment distinct from local developer builds.
In this case, the active configuration during build is set to DEV-CM, or TEST-CM, depending on the environment, and I pass in MSBuild parameters for:
IsDesktopBuild=false
GeneratePackages=true (TDS project properties are set to generate separate code/file packages)
SitecoreWebUrl=ht tp://[host]
SitecoreDeployFolder=\[server][share]\website
In visual studio, the DEV-CM and TEST-CM configuration targets are created and configured for the TDS projects to enforce Deployment settings, multi-project packaging dependencies, etc.
This sends the configuration to TDS's portion of the build, generates the packages (which I have published out as TeamCity artifacts) and performs the TDS deploy to the target URL and target UNC.
I would encourage the route of separate build XML files and specifying that XML file as the target script in the TeamCity build step.
I am currently integrating in web deploy package publish via visual studio and tfs bulid 2010 and have some questions:
For different environments, is a Publish profile needed for each?
As part of the publish is it possible to execute a generated database against a database?
Within the publish profile is it possible to create an application pool, web site, configure it etc if it doesn't previously exist?
Re tfs build - is it possible to click a button to deploy a successful build based on a selected publish profile?
Thanks for any feedback!
I know you're trying to use webdeploy, although most enterprise architecture will use other tooling. I suggest using powershell remoting tools. This gives you the full power of the .NET framework to do database deployments using whatever tools you want.
I usually create different transforms to transform the configuration files. Depending on what environment you deploy to you can use the appropriate transform that matches your environment or manipulate the transform as desired.
Can anyone shed some light on how to get Team Build 2010 beta 2 to push a SQL database project to the SQL server?
In VSTS 2008 you'd just add MSBuild commands with the targets attribute set to "deploy" in the TFSBuild.proj file, but I'm having a little trouble translating that to the new workflow based xaml thing that 2010 uses.
What I'm looking for is how to trigger the actual deployment of the databases themselves. It is already generating the deployment scripts just fine.
For anyone still looking for the answer, use an Invoke Process that uses vsdbcmd.exe:
http://msdn.microsoft.com/en-us/library/ff805001.aspx
Here is an example:
http://www.nablasoft.com/alkampfer/index.php/2009/10/06/deploy-a-database-project-with-tfs-build/
It may be that you are simply missing the DeployToDatabase=true
There is another solution to this problem if you don't need incremental database upgrade. So if recreating the database for each build is ok with you the following would also work.
Add a deploy target to Database Project file
Configure the deployment settings for ‘My project settings’. Those settings will then be used by the build server when building the solution. When building locally, the settings used will be the ones from ‘My isolated development environment’.
In the database project properties
Deploy Action needs to be ‘Create a deployment script (.sql) and deploy the database’; this will prevent the execution of the script, it will only create it.
Database project file
Modify the database project file (right-click database project, select Unload, right-click again, select Edit [ProjectName].dbproj)
from
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
To
<Project DefaultTargets="Build;Deploy" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
When the Build server builds the solution containing the database project, adding the default targets will also deploy the database. This build will use the Deploy settings selected for ‘My project settings’.
Pros
Easy to set up
Cons
Because the default target is changed to Build and Deploy, when a developer do a local Rebuild of the solution, it will also deploy the database (building only won't trigger the deployment)
The closest thing I've found so far is this post from Jim Lamb (the Team Foundation PM at Microsoft).
Here he talks vaguely about creating a custom proj file and modifying the default build process template to invoke the proj file.
He also talks about using the upgrade template, which I'd previously ignored. Apparently the upgrade template can be used to invoke a 2008 build definition. I'd rather not invoke and define the entire build based on the legacy proj file though, but at least it is an option.
Neither topic contains sufficient information for me to actually make the modifications necessary, but it does give me a reasonable starting point for some future experimentation.