I am wondering if anyone has an example of setting a Pre-Build Event (project properties, Build events) on an SSDT project so that we can change a files 'Build Action' from 'build' to None given a project configuration.
Something like: if $configuration is x then set buildAction = 'none' on abc.sql else set buildAction = 'build'
Regards
If you have different implementations of the same stored procedure, then you'll probably have 2 options:
Create conditional logic inside SP. You'll need to define variable value when publishing and in the code you'll have something like:
IF ('$(EnvVar)' = 'PROD')
BEGIN
-- code needed to be executed in PROD
END
IF ('$(EnvVar)' = 'DEV')
BEGIN
-- code needed to be executed in DEV
END
Create 2 (or you might need more) projects that would have that single procedure (or set of objects) with different implementations. Then add the reference to your main project with an option "The same database". Then create different publish profiles in the projects and use proper connection strings there.
I resolved this by using a pre-build event to copy a clone of the stored procs into the correct location depending on the build setting. So I have marked the above as an answer as well.
I could have also used a .tt file to generate the stored procedure at build time.
Related
I built a console app with .Net Core 3.1. I have it building using Yaml leaning heavily on the learn.microsoft.com documentation. The release is pushing to the correct box. But I have an appsettings.json file that has a conn string variable that is different between my TEST, QA and PROD regions. I knew how to do this with the xml file transforms in .NET and MVC but I can't get this to work. Any help would be great since I don't even know the term for what I am trying to do here.
How do you change the connectionstring in the appsettings.json based on a variable or do I have to create 3 branches each with settings and create 3 build and release pipelines?
Thank you.
In order to push to different environments you usually
Have seperate release pipelines that trigger from different branches.
You have one release pipeline with different stages that need pre-approval to move to the next stage TEST -> QA -> PROD.
In both cases you will make use of Stage.
There you need to add a task named "File transformation"
In the File Format select JSON
Now, any variable found in the appsettings.json file will be replaced by the variables you set in the pipeline.
Be careful because nested variables like
{
SerilogSettings: {
BatchSize: 100
}
}
need to be set with a "." instead like
SerilogSettings.BatchSize
We have one ASP.Net solution with several projects. each project have build.pubxml with unique folder path.
For example:
In project Test we have this line inside the build.pubxml:
<publishUrl>C:\publish\SolutionName\Test</publishUrl>
In project Exam we have this line inside the build.pubxml:
<publishUrl>C:\publish\SolutionName\Exam</publishUrl>
In the build pipeline (in TFS) with have MSBuild step with this argument:
/p:PublishProfile=build.pubxml
After the build we got 2 folders - Test and Exam in C:\publish\SolutionName.
So far so good.
The problem is we have few branches, and we want to separate the publish folder for each branch, so we added .pubxml for each branch and in the build pipeline we specified the correct one. but is make are a lot of work on each new branch created and can cause mistakes.
We tried to pass the /p:publishUrl=C:\publish\BranchName in the MSBuild but then we got a one folder with all the content of Test and Exam and not two folders.
The idea is to have only one .pubxml file for each project with a parameter and pass the value in the pipeline, for example:
<publishUrl>C:\publish\$(Parameter)\Test</publishUrl>
And in the build we will pass the parameter according to the branch.
It is possible to do something like this?
It is possible to do something like this?
The answer is Yes. Since msbuild accepts Global Properties in command-line. If we define one Property in build.pubxml like <publishUrl>C:\PublishFolders\$(BranchID)\xxx(Test,Exam...)</publishUrl>, then we can simply pass the value in msbuild arguments like this:
Then we'll get Test and Exam folders under C:\PublishFolders\NewTest. Also we can choose to pass the pipeline predefined variables to the command like: /p:BranchID=$(Build.SourceBranch)...
This works for build in local machine, tfs and Azure Devops pipeline. Hope all above helps :)
I am building Integration tests in Visual Studio (2017) for Net Core applications built on VSTS and deployed from there. My projects are test projects, and right now my connection strings to the deployed API url, and the database are hardcoded, but I want to remove them from the code and place them in a VSTS build step that adds environment variables.
Right now, my Test .cs files look something like this:
[TestClass]
public class TestFeature
{
//Set up variables
private static string _connectionString = "server=localhost;port=5432;database=databaseName;user id=postgres;password=postgres";
[TestInitialize]
public void Initialize()
{
}
//And going into my test methods
}
How do I set up my project to read Environment Variables set from the Configuration on VSTS?
What research has dug up for me so far, is to Right Click on Properties of the test project, under Debug, set up Environment Variables with a key and value there.
Then I change my test project to take the GetEnvironmentVariable()
private static string _connectionString = Environment.GetEnvironmentVariable(nameOfVariable);
On the other side in VSTS, I'm trying to find a build step that will set the variable to be the connection string there. The best step I could find is "Set Variable".
However, this is not working for me. The program will not recognize the name of the new variable set in Environment Variables, to start.
You need to add your VSTS variables in the Variables tab.
Another option is to use Powershell to set them if you want to do it in a dynamic fashion using a Powershell script task.
Write-Host "##vso[task.setvariable variable=sauce]crushed tomatoes"
https://learn.microsoft.com/en-us/vsts/build-release/concepts/definitions/release/variables?tabs=powershell
The better way is building, deploying and testing together in a build definition, after the build succeed, then the pull request can be approved.
For this way, you can use the variable in current build (can add/update variable as Marcote said)
If you must do integration test in a separate build, you can set Trigger to Manual in Build validation of Pull Request policy, then you can queue build manually and specify variables’ values (Check Settable at queue time for the variables in build definition)
Is there a way where the database references in a SQL Server Database project (Dacpac) can be derived at run time?
We're building a product which uses Dacpac to deploy database objects.
Our product implementation teams also use Dacpac projects by adding database reference to the product Dacpac file and then adding their own additional objects to the project.
The problem we're facing is - every time the implementation needs to point to a newer product release version, the parent dacpac references in the implementation dacpac have to be changed manually to refer to the new file path of the new product dacpac (in the newer release). We've mutiple implementation teams and multiple database projects in each implementation.
Is there any way the database references (*.dacpac) in a database project can be derived at run time using a variable or parameter or something of that sort?
My understanding of your question is as follows:
You have a SSDT database project (see example image below), that has a database reference (similar to #1 below) with stored procedures and other db objects that access the reference database (similar to file #2 and code #3). You've 'built' the solution resulting in a DACPac and now you want to take this DACPac and reference other databases at deploy-time. Hopefully I understood your question correctly.
If so, then you can use the Publish Profiles feature to achieve this (similar to #4 below).
The code for this can be seen in my notes from my SSDT talk github project.
If you look specifically at the demo04 solution file, you will see that I have a DEV_MJE.deploy.ps1 PowerShell file and a DEV_MJE2.deploy.ps1 file. These scripts run MSBuild to build the DACPac and then use SqlPackage to publish DEV_MJE.publish.xml or DEV_MJE2.publish.xml respectively. Note, if you run this example on your machine, you'll need to add MSBuild.exe and SqlPackage.exe to your path, as well as modifying the TargetConnectionString in the xml files to an existing development database.
As an example of how this works...When I use the Publish Profile DEV_MJE.publish.xml, the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE].[dbo].[AnotherTable]
Whereas when I use DEV_MJE2.publish.xml the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE2].[dbo].[AnotherTable]
Notice the database reference in the second has changed to AnotherDb_MJE2.
For a good description of how Publish Profiles relate to DACPacs and SSDT Database Projects, see this web page. It also contains information on alternative ways to deploy beyond SqlPackage.exe.
Something else to consider
Note, that using file paths to version control a DACPac is not really the best practice. Consider the DACPac artifact as similar to a .Net DLL. It is the biproduct of a build.
As such, a better approach is to use NuGet and tools like Octopus Deploy to store, track, and deploy DACPacs. See the stackoverflow answer for a good description of how this works.
Hope that this helps,
Michael
Thanks for the followup comment, I think what you are trying to do is when you write and deploy your code be able to use different dacpacs depending on the project?
Each implementation team might have a different version of the shared dacpac deployed so you can't just put the files in a shared location and call the dacpac "Product_Latest.dacpac" or something, so everyone always gets the latest version.
".sqlproj" files are standard msbuild scripts and references can be managed using msbuild properties so you can technically change the reference at runtime. If you edit your .sqlproj file and add a property in the first <PropertyGroup> tag, I used:
<ProdDacpacVersion Condition="'$(ProdDacpacVersion)' == ''">v1</ProdDacpacVersion>
v1 is the unique name for the version folder - you just need something to identify the dacpac you want.
I put the property just after TargetDatabaseSet and IncludeCompositeObjects.
If you then find the reference to the dacpac and instead of
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\v1\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\v1\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Use the property from above:
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Then the reference will use the property to get the path of the dacpac. There are a few ways you can set the property, you could edit the .sqlproj file when you want to take a new version of read the property from a file or environment variable or something (i'll leave the msbuild fun to you!).
I would, as a standard, everytime the reference was changed either reload the project or restart visual studio - it won't take long and it will save lots of cursing :)
When you deploy the dacpac's, the deploy looks in the same folder for references first so just make sure you copy the right one into the bin folder when you deploy.
I use two build configurations.
Root
Sub
The buildfile for 'Sub' requires a environment parameter 'Param' to run. Can I pass this parameter from my 'Root' configuration to the 'Sub' configuration in Teamcity.
Each build configuration has a configuration code i.e. bt123
Let's say your Root configuration has the code, bt123, and has a variable called java_dir
Your Sub configuration, can reference it like this
Name: JAVA_DIR
Value: %dep.bt123.env.JAVA_DIR%
The easiest way to do this, is to select the small box with lines in the right of the text field, "Value". This will provide a drop list where you should be able to find the variable from bt123.. Just start by typing bt123, and you will see all the variables available.
Hope this helps.
Here is a link to the version 10 documentation regarding dependency properties.
https://confluence.jetbrains.com/display/TCD10/Predefined+Build+Parameters#PredefinedBuildParameters-DependenciesProperties
These options have been available since at least TeamCity 8.x.