Hello! Some weeks ago I got the tests working on the CI build for PoshSSDTBuildDeploy. The tests were a bit of a mish mash, however they sort of did the trick. Thankfully Eugene Niemand came along and very kindly offered to update the tests into Pester tests, and also just generallytidy up the mess. It’s always great to have a second pair of eyes on any code, as it helps it from not being quite so auteured…
Hello! I have recently been creating a pipeline in VSTS that will check if certain software/PowerShell Modules are installed on the box, and if it isn’t then install it. It’s a sort of a DSC/Chef/Puppet process done via VSTS so that I don’t have to configure the aforementioned software. But I needed a way to target a specific build agent to run this build on; specifying an agent pool is no good as it will deploy on any in that pool.
Hello! I’m currently working on a project that requires building and deploying SSDT-based projects. So it’s been a great opportunity of making use of PoshSSDTBuildDeploy and work through any issues. And there have been a few minor updates to the module over the past fortnight which I’ll go through now! As I type the latest version is 2.196.0. Return Path of MSBuildDataTools - Just so much easier to have location returned so that when you execute Invoke-MSBuildSSDT and Publish-DatabaseDeployment you can just pass the outputted variable in.
(If anyone actually gets the reference: kudos. If not, then it’s just that you’re not a Soundgarden fan)
So, there’s something that has been troubling me about deploying to databases with SSDT for some time. Actually, it’s not a SSDT-exclusive problem per se, it’s more of a database/release management process.
What it pertains to is that most people like to create the deployment script for review prior to deploying to production. This makes sense if you are new to the Continuous Deployment process, and that maybe sometimes SSDT creates scripts that are not quite expected. You may skip this because you feel rather more confident in your deployments, or the database sufficiently simple enough to just deploy without having to review. But generating the script as a deploy artefact is still a good idea, because auditing.
At any rate, the script is generated and maybe reviewed….. so then what? In SSDT there is no way to create and deploy script in one step; they are two distinct steps. And even if they were one step, this would still not resolve the issue that troubles me. So what is this issue?
The issue is that by creating a script, and then running the deploy, you cannot be sure that the database is in the exact same state that it was when the initial script was generated. If you don’t already know, SSDT runs a deploy entirely in memory, so as mentioned there is no script created. You have to explicitly create the script as part of the process. Or, if you have already created one, you have to re-create the script.
Hello!
You will need client tools installed as part of your SQL Server installation or the dlls won’t be on your box. Either way just search for those dll names in “C:\Program Files (x86)\Microsoft SQL Server" and they will probably be found.
Edit: MSSISBuild has been updated and moved to GitHub. Read about it here. The rest of this post is still relevant, it’s just where you download the code form that has changed. this has proven to be a popular post, and the software has been downloaded a few times. I will post an update for SQL Server 2016 soon, though I think it is just references in the solution that needs updating.
Today I am pleased to announce the release of MSBuildSsis2012 on Codeplex. But before i get into what it does first, a bit of background:
Back in May, and subsequently a few more times since, I’ve posted about an error I get occasionally in one of our custom tasks that run in our builds. This custom task is a special case: As the SSIS 2012 project extension is dtproj, it cannot be compile using MSBuild. The typical solution would be to use DevEnv In MSBuild. And to automate deployment the solution (that would work for most people) is to use the SSIS Deployment Wizard in silent mode. However, we don’t use the SSIS Deployment Wizard in our automated builds as it does not work in Silent Mode when you have assembly references in the SSIS packages: it destroys those references and the dtsx packages fail whenever they run.
Things have been quiet on the blogging front, the reason being that house buying/selling has become a major distraction. Plus any time I do get I’ve been looking at Clustered Columnstore Indexes. The more I read about them the more I’m impressed by what Microsoft and the bods on the SQL DB Engine team have achieved here. If you want to read more about clustered columnstore indexes I suggest you check out my previuous posts as there are plenty of links to pique your interest.
Wow, a new years resolution I’m following through with! This year I’ve already passed 2 Microsoft Exams. The first exam was “Querying Microsoft SQL Server 2012”, and some of the skills I learnt from studying for this exam has helped me write better scripts, 1 of which was posted yesterday. So I’m 1/3 of the way towards achieving the Microsoft Certified Solutions Associate (MCSA) SQL Server Solutions Associate certification.
The second exam I passed is the “Delivering Continuous Value with Visual Studio 2012 Application Lifecycle Management”, which (along with the testing and TFS exams) is necessary for achieving the Microsoft Certified Solutions Developer Certification.
( Part 2 focuses on clearing out the SSISDB by creating new stored proc based on the one used by the maintenance job. If your Maintenance Job is taking hours to run, you need to check this out.)
When deploying our Ispacs through my builds, I’ve still been getting the intermittent “timeout” issues I first wrote about back in May, and this has been exacerbated by extra SSIS Projects added to the SSISDB catalog.
I’m in a bit of a Property Function mood at the moment with our builds. We generate a GUID within our builds for an Id required in one of our config file and some more for our WiX installers. There’s two ways to create GUIDs. Which one you use really depends on what version of MSBuild you are using.
Not so long ago I posted about string manipulations in SQL. Seeing as I recently had to use the MSBuild property functions I thought it best to post a fairly advanced example of using the .Net property functions in MSBuild as most of the examples I have found online are useful to no one. The kind of example I am talking about is found on the MSDN page:
[code langauge=“csharp”]
$(ProjectOutputFolder.Substring(0,3))
How to: Use the Same Target in Multiple Project Files.
Further to my post yesterday about Importing projects in MSBuild, it’s worth having a quick read over the “Order of Evaluation” section to understand further that it is important where you import a project if you wish to set the properties and items of the imported project.(TL;DR -
Hello, you can probably tell from the title of this blog that I’ve had a frustrating morning trying to overcome a limitation in MSBuild when importing a project.
So new week, new post, and getting back to what I really started this blog. I like sharing knowledge, but part of the reason I blog about new versions of software is so that it motivates me to read up on what’s coming up, but the post today is typical of what I enjoy writing about the most. This post is about how to get projects that are unsupported by MSBuild built in an automated build.
(Update: Part 2 focuses on clearing out the SSISDB by creating new stored proc based on the one used by the maintenance job. If your Maintenance Job is taking hours to run, you need to check this out.)
No WiX Wednesday this week, owing to commitments in real life. Instead, here is something regarding SSIS 2012 Deployment. Enjoy!
As part of our CI and Test Builds we have automated the deployment of two SSIS Projects. One is fairly large and the other one contains only two dtsx packages. Recently we have been getting timeout issues with the deployment of the solutions.
Today has seen the release of Visual Studio 2012 – Update 2 RTM. There have been severaliterations of Update 2 in the form of CTP. IN fact I think if I recall the CTP 4 was RTM for TFS 2012 but not for Visual Studio 2012. Regardless, the RTM is ready to download. You can get it via this link below, or when you boot up VS 2012 a new download should be available. If you missed out on Update 1 then it is installed as part of Update 2…
Today has seen the release of Visual Studio 2012 – Update 2 RTM. There have been severaliterations of Update 2 in the form of CTP. IN fact I think if I recall the CTP 4 was RTM for TFS 2012 but not for Visual Studio 2012. Regardless, the RTM is ready to download. You can get it via this link below, or when you boot up VS 2012 a new download should be available. If you missed out on Update 1 then it is installed as part of Update 2…
Based on a previous post about TFS Build Server Best Practices,I thought I’d share the stack I install and a few of the steps that I go through to get the build server working. Obviously your experiences will be different to mine, and I don’t recommend that you follow this to the letter unless you have a similar set of solutions to build. I’m also going to assume you have Windows Server installed and your build service up and running, there are plenty of blogs and MSDN articles that show you how to set this up.
Update August 2016: If you can, use the VSTS Hosted Build Service. If you can’t, then you’d be surprised to know that the Hosted Build Service uses the D2_V2. Which is 2 core, 7GB of RAM. For 1 build agent. So you know…. something to consider there….
(Update 2014: below I mention that 2GB per agent is a good starting point. This is probably not enough if you’re publishing/scripting database changes using sqlpackage.exe, particularly if one of the databases is a multipartitioned data warehouse and you plan on having multiple builds running simultaneously. I’d say 4GB, if you can afford it, per agent for this scenario).
It’s amazing how important build servers are to a team working in Scrum; the team relies on a fast build server that can build and deploy code quickly. A CI Build gives the devs feedback that the code is good to be deployed to the test environment. And the testers rely that the build deploys to the environment rapidly. If it takes 10 minutes to run a CI build and 20 minutes to deploy to a test environment, that’s half hour spent on waiting to test a new feature. Over the period of a sprint, many builds are run, which leads up to a significant amount of time waiting on builds. Invariably the developers and testers whinge that the builds are taking too long, and the boss comes up and asks you to find out why they’re taking so long and speed them up. So based on my experiences here are my thoughts on how you can check that you’ve optimized your builds and build servers as much as you can.