Salt and AssistDeploy Get Updated
Hello!
Having already randomly mused this month, here’s some more!
Hello!
Having already randomly mused this month, here’s some more!
Hello!
Some random musings on some things that aren’t worth a blog post on their own, but I want to talk about anyway.
Hello!
I’m currently working on a project where we are using git as our source control, and so we have created branch policies on master that specify a specific VSTS build must be green before a pull request can be accepted. This is great, because what I like to do with any pull request is pull the branch and run the build, deploy and test scripts to make sure that at the very least, all this passes. So by adding the builds as a branch policy at least gives a thumbs up, at least in the sense that the code compiles.
Hello! So, I’ve been working on a project recently where we’ve been using an Azure SQL Database that is stored in source control as an SSDT Project. We’ve also been making use of the excellent TSQLT to run unit tests as part of the build. And typically I set up a Unit Test database to reference the main database so that the tests can be deployed separately from the main code.
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’ve recently started a new project, and we’re going to use VSTS for the build and release pipeline. This includes deploying infrastructure from ARM templates. This is going to provide its own set of challenges, in that the VSTS Team is new and there is no authentication between VSTS and the Subscription the objects are deploying to. So it really is a “green field” project. But this is a good thing, as we get to deploy as much as we can from source control and limit the interaction with the Azure Portal.
I was interested to know just what the hardware specifications of the hosted build agent is. So I added some PowerShell to read out the info below: 2016-06-29T09:23:31.3935358Z systemname Name DeviceID NumberOfCores NumberOfLogicalProcessors Addresswidth 2016-06-29T09:23:31.3935358Z ---------- ---- -------- ------------- ------------------------- ------------ 2016-06-29T09:23:31.3935358Z TASKAGENT5-0010 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz CPU0 2 2 64 2016-06-29T09:23:31.4095356Z Total memory: 7167.55078125 What piqued my interest greater was that this is the exact same spec for a D2 v2 box that is available via Azure.