Solenopsis

Standard picklist changes Winter '17

by Patrick Connelly posted on November 24, 2016

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.


GlobalPicklist changes in Winter '17

by Patrick Connelly posted on November 11, 2016

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.


Quick Deploy with Solenopsis

by Patrick Connelly posted on August 22, 2016

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.


Solenopsis with XSLT

by Patrick Connelly posted on July 22, 2016

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.


Using Git with Salesforce and distributed teams

by Patrick Connelly posted on July 21, 2014

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


Auto watch a directory and rebuild the repository when an rpm is added/updated

by Patrick Connelly posted on December 19, 2012

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.

import re
import httplib, urllib
from subprocess import call

ROOT_DIR = '/path/to/dir'

wm = pyinotify.WatchManager();
mask = pyinotify.IN_CLOSE_WRITE

def pushover(message):
        conn = httplib.HTTPSConnection("api.pushover.net:443")
        conn.request("POST", "/1/messages.json",
        urllib.urlencode({
                "token": "TOKEN",
                "user": "USER",
                "message": message,
        }), { "Content-type": "application/x-www-form-urlencoded" })
        conn.getresponse()

def gen_repo():
        pushover('rebuilding repo')
        call(["createrepo", ROOT_DIR])


class EventHandler(pyinotify.ProcessEvent):
        def process_IN_CLOSE_WRITE(self, event):
                if event.pathname.endswith('.rpm'):
                        gen_repo()

handler = EventHandler();
notifier = pyinotify.Notifier(wm, handler)
wdd = wm.add_watch(ROOT_DIR, mask, rec=True)

notifier.loop()