Skip to main content


Showing posts from November, 2018

Azure Devops, unit tests and Azure AD Service Authentication

I couldn't think of a title for this one that wasn't ridiculously long so to help future Googlers, here's what we were trying to do:

Authenticate against Azure Key Vaultusing a Service Principalusing Azure AD Service AuthenticationRrom our build serverRunning an Azure Devops build agent
Whew.  Basically we had some integration tests that retrieve a database connection string from an Azure Key Vault, and needed Azure Devops to be able to run those tests on our build server. Which meant it has to authenticate with its own service principal in Azure AD as described in here:

We were using the certificate-based method, to request a token to access the Key Vault, but it wasn't working :(  In case I run into this again, here's the steps we had to go through to sort it out:

Don't get the cert thumbprint from the certificate properties, get …

Making EntityFramework play nice with Azure Key Vault

Make a separate class containing a constructor to pass in the connection string from KV.  Don't modify the constructor in the Whatever.Context.cs file because it'll get regenerated when you update the model and overwrite any changes you make in there.

Get the connection string from the "update model from database" command, but replace " with actual quotes. The connection string in KV should look like this:

metadata=res://*/EntityFramework.DataWarehouse.csdl|res://*/EntityFramework.DataWarehouse.ssdl|res://*/EntityFramework.DataWarehouse.msl;provider=System.Data.SqlClient;provider connection string="data;initial catalog=thedatabase;user id=dbusername;password=passwordgoeshere;MultipleActiveResultSets=True;App=EntityFramework"

Salesforce - bypass running unnecessary unit tests during a deployment

We had to urgently fix a bug in an Apex class written by a previous colleague, which was causing major issues with a customer-facing application on a Friday afternoon (because these things always happen then).  We'd found the bug and updated the code easily enough, but Salesforce's default deployment option of running all local unit tests was failing because of some completely unrelated tests that were failing.

Salesforce's documentation (or at least the parts that I read) doesn't clarify that you aren't actually required to get 75% code coverage across all Apex code in your production org - you only need to get 75% coverage over the code you're deploying.  Here's how to do it and get that emergency fix into production asap.

You'll need the CLI for this, which you can easily install via chocolatey here.  You can probably do the same with the Salesforce DX CLI, but I'm used to this other one.

Make a dev sandboxIn production Salesforce deploy…