Quick Deploy with Solenopsis

Solenopsis with quick deploy
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.

quick deploy status

In order for the deployment to succeed, you have to meet the code coverage requirements for the classes you are deploying.  For example, if we are deploying BaseTrigger.cls we have to run enough tests to get at least 75% code coverage for that class.

Caveats

  • You have to have the correct amount of code coverage for the deployed code
  • You do not have to include the tests (if they haven’t been updated) in your package, but you do have to mention them in the XML (Solenopsis handles the mentioning bit)
  • The deployment expires after 96hrs and must be re-run after that timeframe
  • Any changes to the org’s metadata can invalidate the deployment and will require the deployment to happen again
  • Quick deploy only works against production orgs and cannot be used against a sandbox or developer org

Quick Deploy with Solenopsis

Shortly after this feature came out of pilot, we added it to Solenopsis.  We have been using this as our primary way of deploying code to production and it’s great.  We went from having a deployment window on the day of from 5hrs to less than 30min.  The amount of time the job runs to do the deployment varies from deployment to deployment but that time doesn’t require any real downtime or notification for our users.

Prep Work

To get your code ready to use the quick deployment feature you’ll need to add a javadoc annotation to denote what test classes need to be run.  For this example, we’ll be taking a look at the code our Escalations application.

Trigger

/**
* Trigger for escalation cases
*
* @author Patrick Connelly ([email protected])
* @testClasses EscalationCaseTrigger_Test
*/
trigger EscalationCase on EscalationCase__c (before insert, before update, before delete, after insert, after update, after delete) {
	EscalationCaseTrigger t = new EscalationCaseTrigger(Trigger.oldMap, Trigger.new, Trigger.isBefore);
}

Class

/**
* Trigger work for escalation cases
*
* @author Patrick Connelly ([email protected])
* @testClasses EscalationCaseTrigger_Trigger
*/
public with sharing class EscalationCaseTrigger extends BaseTrigger {
    // Code removed for brevity
}

Explanation

In the code above, you can see that we’ve added the @testClasses annotation.  This is a comma separated list of class names to run.

Usage

Any of the standard Solenopsis commands can be run with the --fast parameter.  The most useful of the commands is the delta-push as it will determine what is different on disk from what is in the target org and then only add the tests needed to cover those classes.

Doing the deployment is as simple as

solenopsis --fast delta-push

This will generate our destructive changes xml as well as parse the @testClasses and generate the correct XML to denote the test classes.

Posted in Developement, Salesforce | Tagged , , | Leave a comment

Visibility for Apex in Managed Packages

apex visibility in managed packages
Now that I’m starting to spend time playing with packaging code for use I decided to dig into how access modifiers affect visibility of methods and classes inside of managed packages.

Visibility Access Modifiers

Before we get started, let’s review what options we have for defining visibility in Apex

private – Methods, classes and variables marked as private are only visible inside the same class.  If you define something as private then it cannot be accessed from an external class

public – Things that are marked as public are available for use by anything in the same namespace.

global – Things marked as global are available for use by anything on the platform.

Typically, public and private are enough for most implementations since your code resides inside the same namespace.  When writing code to be used by others from your managed package you’ll want to make it global.

Continue reading

Posted in Developement, Salesforce | Leave a comment

Heatmap for Contact Locations

Geocoded heatmaps
One of the cool new features in Summer ’16 is the ability to take a built in (or custom) address and automatically get that addresses latitude and longitude with SOQL (Read More).  So took this as an opportunity to learn some more about it as well as some other mapping technologies.  So for this my goal was to be able to create a heatmap of all the contact’s location under an account and place this on the account page.

Continue reading

Posted in Developement, Salesforce | Tagged , , | Leave a comment

Opensource Update

This week is going to be just a social update on a couple of projects that I’m working on.  I’ve got plans for a big neat post next week.

Me Code Pretty One Day…

I was hoping to present this at Dreamforce this year but it doesn’t look like that’s going to happen.  So instead I’ll just talk briefly about it here

Apex Styleguide – Link – I’ve been asked several times what our team does for it’s code style and I’ve been working on an online style guide.  It’s really a work in progress and will probably pivot a bit once Apex Checkstyle is complete.  Right now all the rules are enforced by regexes and it doesn’t scale well and has a lot of false positives.  If you want to create your own styleguide, feel free to fork the project.  I’ll add build instructions for the site soon to make this easier.

Apex CheckstyleLink – This has been something that’s been in the works for a while.  Initially I tried to just make an extension to Checkstyle but there was just too many problems with that.  So instead I completely forked Checkstyle and modified the grammar to help support Apex.  While the project builds and it works on some very simple Apex code, it’s nowhere near ready for the big time.  I’m going to keep working on it and hopefully someday soon it’ll be ready.

Other Projects

EscalationsLink – Another project still very much in it’s infancy.  The idea behind this is to make an easy way for support centers to track escalations to cases.  The plan is to have this both as a managed package as well as having the source available if you want to install it as unmanaged code.

SalesforceAppsLink – This is just a repo for random code that I’ve worked on that others may find useful.  Right now I think the most useful bits are under the node_scripts directory.

Hands On TrainingLink – Training is in my blood and it’s something I’ve always loved doing.  You should checkout my hands on training.  I have plans to migrate some others over to it as well as writing a couple more.  You can follow the project if you want to be notified of updates.

Posted in Developement, Salesforce | Tagged | Leave a comment

XML Parsing in Apex

Doing XML parsing in any language can be pretty tough.  I wanted to share a quick how to for doing XML parsing in Apex based on a previous board post.

Let’s start with the data we’re trying parse

<?xml version="1.0"?>' +
<_CREDIT_SCORE for="Bob Dole">' +
  <_CREDIT_SCORE _CreditScore="668" _ReportingAgency="Experian" />
  <_CREDIT_SCORE _CreditScore="658" _ReportingAgency="TransUnion" />
  <_CREDIT_SCORE _CreditScore="660" _ReportingAgency="Equifax" />
</_CREDIT_SCORE>

For this data we want to pull out who the credit report is for and the credit data from the for field as well as from each of the _CREDIT_SCORE elements the agency and the score.

Continue reading

Posted in Developement, Salesforce | Tagged , , | Leave a comment

OAuth Flow for service users in Salesforce

oAuth and Salesforce
A very common use case for integrations with external systems is to have a service user that is authenticated and all subsequent interactions happen via that user.  This flow is super easy when you can do username / password auth, but it becomes much harder when you’re only option is to use the oAuth flow.

Use Case

In a recent developer board post, a community user asked for help storing their credentials from the oAuth flow to box.com and then create a new folder whenever an account was created.  The problem they were facing is that when you do the initial oAuth flow, you have to approve the use of the app and this requires human interaction.  This is not something you can do inside of a trigger, so we’ll need to find another way to do it.

Continue reading

Posted in Developement, Salesforce | Tagged , , | Leave a comment

SoapUI TLS 1.2

SoapUI TLS
Soon, Salesforce will be requiring all connections to be TLS v1.1 or higher.  This poses a problem for anyone using SoapUI with Java version 1.7 as that version of Java does not have TLS 1.1 or higher enabled by default.  If you attempt to connect to an instance that has the “Require TLS 1.1 or higher for HTTPS connections” enabled you will get an error like the following

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sf="urn:fault.enterprise.soap.sforce.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>sf:UNSUPPORTED_CLIENT</faultcode>
            <faultstring>UNSUPPORTED_CLIENT: TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.</faultstring>
            <detail>
                <sf:UnexpectedErrorFault xsi:type="sf:UnexpectedErrorFault">
                    <sf:exceptionCode>UNSUPPORTED_CLIENT</sf:exceptionCode>
                    <sf:exceptionMessage>TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.</sf:exceptionMessage>
                </sf:UnexpectedErrorFault>
            </detail>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

Continue reading

Posted in Developement, Salesforce | Tagged , , , , | 12 Comments

Parse JSON with Reserved Words

JSON Logo
One of the great things about Salesforce when dealing with external webservices is being able to easily parse JSON into Apex classes.  I’ve covered this in several previous posts.   However a common problem is that the system you are integrating with is they may be using a variable name that is reserved.  With the following data, we can see that there is a variable named “case” if we ant to parse this data into a Apex class we won’t be able to because case is a reserved name.

{
    "data": [
        {
            "case": "123456",
            "subject": "Test case"
        }, {
            "case": "789012",
            "subject": "Another case"
        }
    ]
}

Continue reading

Posted in Developement, Salesforce | Tagged , , | 3 Comments