I wrote a couple of weeks ago I wrote about the GlobalPicklist changes in Winter ‘17. This past week I learned that there was another change in the release notes that I overlooked.

After updating the Case object to API 38.0 I didn’t notice that the Case.Type field had changed. In API 37.0 this is what the Case Type field looks like

<fields>
    <fullName>Type</fullName>
    <inlineHelpText>The case type</inlineHelpText>
    <picklist>
        <picklistValues>
            <fullName>Value 1</fullName>
            <default>false</default>
        </picklistValues>
        <picklistValues>
            <fullName>Value 2</fullName>
            <default>false</default>
        </picklistValues>
        <sorted>false</sorted>
    </picklist>
    <trackFeedHistory>false</trackFeedHistory>
    <trackHistory>false</trackHistory>
    <trackTrending>false</trackTrending>
    <type>Picklist</type>
</fields>

And this is what it looks like in API 38.0

<fields>
    <fullName>Type</fullName>
    <inlineHelpText>The case type</inlineHelpText>
    <trackFeedHistory>false</trackFeedHistory>
    <trackHistory>false</trackHistory>
    <trackTrending>false</trackTrending>
    <type>Picklist</type>
</fields>

In the turmoil of all the other changes to the object file, I completely missed the change. And when the deployment failed I was at a loss to figure out why. The failure wasn’t about the picklist in particular, it was about the picklist value in a record type.

Like many companies, we have a deployment process in place to handle changes in seasonal releases in Salesforce so that when a sandbox is ahead of production, we can still deploy to both without having to wait for production to be updated. Then, after both the release hits production, we go through a manual process of updating the API (primarily the ant-salesforce.jar) and the metadata to the most recent API version. Typically this just involves updating the jar and updating the API version in the request, pulling down the updated metadata and writing it to SCM. However, with the Winter ‘17 release we saw a problem trying to deploy our GlobalPicklist files after updating the API.

In Spring ‘15 Salesforce released a feature called “Quick Deploy” that allows you to only run a small subset of tests when you do your deployment instead of running all the tests. When you’re in an org like ours that running all tests can take upwards of 5hrs (or longer if the moon is aligned incorrectly) this is wonderful. Let’s take a look at how quick deploy works and how you can use quick deploy with Solenopsis.

How Quick Deploy Works

Quick deploy simply runs a provided list of tests when you run your deployment. This deployment is then staged under your Deployment Status in setup. Once the all the tests have run you’ll get a button that let’s you quick deploy.

There’s a great feature we use all the time in Solenopsis that isn’t as documented as it should be. This is the ability to write an XSLT to apply to your objects at time of pull, push or both.

Introduction

I’ve been asked several times (and have presented a couple of times) on how our team handles doing Continuous Integration (CI) and Continuous Deployment (CD) with a distributed team. However one of the points that I’m always asked is specifically how we use Software Configuration Management (SCM) with this processes. For this blog post I’m going to do a deep dive into our process.

NOTE: This process is by no means the end-all-be-all process for everyone. This is just what we have come up with (generalized for public consumption) over several years of developing on the Force.com platform

Today I started setting up the repository for people to use to install the Solenopsis rpm. The problem is I want to be able to build the rpm (via Jenkins) and push it to a remote server and automatically have the repo rebuild when it sees an rpm updated or added to the directory.

To do this, I wrote a small python script that can be run and backgrounded. It sends a pushover notification and runs createrepo against the target directory.