Salesforce and Github Integration

Alright… in the past 6 months I have done enough with Github that I am going to become a shill and start to really recommend serious solutions utilizing a bunch of different features that the Github platform offers (free and paid… this epiphany though is without ever signing up).

From what I’ve read there is 2000 free minutes of runtime for a pipeline runner, and after that you have to start to pay and go a more “business” route.

One downside also is the pages functionality which I will ramble on about forces you to make it public facing to support a Jekyll auto site builder solution.  I did not look too deeply into this, but the gist (see what I did there?) of it was only paid Github accounts can be “private” for the repo when you convert your repo to a GitHub pages repository.  Here is a link to their Pricing if you are curious.

With Microsoft owning github, it seems counterintuitive to be getting so heavily coupled with Salesforce, but a lot of the functionality in Github I propose would be to support a SF Devops setup.  Salesforce at the time of this writing (oct 2021) is really trying to get their sea-legs with some devops related industry best practices and how LWC development is molding

the worlds together of a non sf engineer vs. sf engineer.  Things like node and node modules and packages seemed to be shyed away from before there were so many javascript controlled apps out there where you had to interface with javascript all day.

Corporate Monstrosities aside,  I think SF will have to compete with Github in this space in some way…. And SFDX is the CLI option from Salesforce where you would start to concern yourself with all of the nuances of a repository.  ISVs and developers in the SF ecosystem are going to adapt to these new technologies and SF has to have some cloud solution to version your SF code.

There are so many other providers out there like Github, TravisCI, bitbucket, etc., but if you look at the history of SF and them gobbling up companies like Mulesoft… the pattern of acquisition hans’t hit the source control provider space.   I feel like SF will hate-spend out of their inferiority to Microsoft in this perspective, and we will have to wait and see.  In the mean time though….

As part of a hypothetical DevOps application in SF,  we are going to investigate connecting Github, Salesforce, and Pivotal Tracker as a trifecta of DevOps, SF Ops, and Project Management.  The integrations should provide value in their own standalone way, but I think the real power is when we can utilize all 3, and use SF as the “hub” or “source of truth” where we configure and control the moving pieces of the integrations.

Designing the Product for Salesforce and Github Integration

Every app that is developed is part of a Product or is a Product in terms of looking at Product Owner/Manager responsibilities.  May not be totally correct to refer to any old Dev as a Product Owner/Manager but in essence they are, and on development teams you will hope for a Product Owner/Manager to drive specific decisions and directions for the Product your team is developing.  Not all companies have this luxury, but you will find a lot of references to roles and expectations that may not be comparable between a startup and a mega corp.

If we are to make this tutorial set as real as possible, let’s agree that our “Product” we are looking to create is the application that will integrate the Project Management tool, Salesforce, and the Source Control tool.  While the specifics like Github and Pivotal Tracker are quite specific, they are still part of the apps any company would use to do those PM and Developer work management.  We could have done a JIRA to Salesforce integration and used source control that is deeply coupled with JIRA to solve the same business problem or need.

Azure Devops, JIRA, and other products also have extensive APIs that allow full customization almost, and the app we build could be extended to those platforms as well if you want!   But, for now, we will keep it focused as our Product being a SF App to Integrate with Github and Pivotal Tracker.   We are the Product Owner/Manager and can keep the existence of that role in mind for knowing where directionally an App can go while it’s being built.

keep it focused as our Product being a SF App to Integrate with Github and Pivotal Tracker.

Technical Documentation for Salesforce and Github Integration with Pivotal Tracker 

Here is a diagram that overviews the connections involved with our planned Product that we are building in these tutorials.  We are laser focused on just the smallest

That diagram may be information overload, but it’s part of what the ideation for the app has seen while it is planning to be developed… and creating the documentation helped me to conceptualize the whole idea and have definitive requirements to code to.

If it is information overload, then let’s get back on track and think of JUST this Github / Salesforce connection:

An example that illustrates this could be,  giving the functionality to pool sandboxes that can be used by developers.  Wouldn’t it be nice if we had something automated to create a new sandbox in certain scenarios, specifically that scenario being 4am every night so that it’s ready for the day?  Have you had to sit around and wait for a sandbox to provision before doing work (and now have 30 minutes to kill?).  One of the features of our hypothetical app will be to simplify the sandbox creation process, but more to come on that later.

Note:  Pro-tip:  Skitch is the app I used to take the screen shot of the existing diagram and mark it up to simplify it.  Skitch is a cool app on the Mac and probably Windows for screenshots that I suggest… screenshots seem to be very common throughout the days.

Including Pivotal Tracker in our Salesforce and Github Integration

Use Cases for the Integration

Now let’s take that a step further, and say for any BUG story that is created in Pivotal Tracker, we want to create a Sandbox, and attach the details of that sandbox to the ticket for the developer.  Now we are using all spokes in this wheel and ensuring that the Bug ticket creation TRIGGERS the sandbox creation, so that hour or 2 waiting to create a fresh sandbox to get a fresh version of Production can happen immediately before the Dev even knows the ticket is out there.

Let’s take it yet another step further and say we want to add a step to load some data in this org once its created…. Or that we want to slack notify that a bug ticket has been opened and paste the link to Slack (which is configured to support a Salesforce AND Pivotal Tracker integration).

There are so many cool possibilities out there to do cool things with these apps to save time, make your workflow more efficient, and start to get the most out of these products that you are already spending money on.

For our intents and purposes though, let’s focus now on connecting Salesforce to Github.  We are trying to facilitate that our configuration and metadata in SF is backed up into the cloud, and into a repository whose purpose is to house code and keep track of versions.    I mentioned above how the SF DevOps scene is being baby stepped into the idea of deploying code from a Repo (as opposed to a sandbox which isn’t a version control system, but an environment)… and all of that has the major prerequisite of having the repository and being able to contribute to it.

Note:  Pro-tip:  Shiny Object Syndrome is something that I heavily fall into with Apps.  Mentioning this because with our push it to the limits paragraphs above we are scope creeping ourselves and not on topic anymore.  Reign it in.  Don’t let the shiny objects ruminate you to uselessness.

Final Pre-Prototype Thoughts on our Tool

Alright, now we can get into the nitty gritty steps and start having some actionable things to do.  The idea of this blog is supposed to be a way for me to socialize these ideas in my head,  while also creating a blog and a brand for myself to eventually market a product around this process.  I’ve spent 10 years in the SF ecosystem seeing how the lack of documentation and lack of a source controlled repo of your metadata has caused a bunch of issues.

I feel it in my bones that there is a need for these things,  but also feel a strong calling to trying to help people get their feet wet in some of these areas.  There will always be people who don’t have the time to play around with VS Code, and SF Development, etc, and that is where I can sell myself as a service to execute some of the things I’ve explained here in this blog.

If all goes well I will have contributed to the community, come up with some cool ideas, and created a tangible product that will allow all of these moving pieces in the app to be a turnkey solution that can get the work done in an automated fashion.  Only time will tell if it ends up helping anybody, but I digress, let’s move to progressing in our App.

A rough outline of what we are going to accomplish is below.  I will try and explain the concepts several times in different ways to get all the ideas out,  but it’s important to point out what the individual pieces are.  In the beginning / solutioning stages, that also helps to journal some ideas since your brain seems to piece things together better when you write things out and finish the thoughts,  so these details are also a requirements exercise and even a documentation exercise.

Action Items in our Salesforce and Github Integration tasks to architect the Solution

1. We create Salesforce and Github Accounts
2. We create a Github App to start process of allowing access to our accounts (or whoever’s credentials used to do the connection).  Github Admin would need to create the app and coordinate some very light setup.
   1. The Github app has a specific configuration for a “Callback URL” that we will set at App Creation time.  This is important because it is our way of giving a response that sends to a URL I configured, so that when you navigate to the callback URL it says “OK, this part of the authentication flow checks out”- in terms of having access to control what URL I just got navigated to, so if we get redirected to it we know we are authenticated.
   2. If the URL doesn’t match the callback error will fire and the connection will not be completed.
      It will give you some message about them not matching up details wise and can be a confusing topic when initially learning about OAUTH 2.0.  That is a cripplingly simple way to describe it, and is my layman explanation I suppose.  I still after 5 years or so get confused by OAuth, so I will share this link to anyone who really wants to dive into OAUTH as a topic.
3. Create SF Named Credentials/ Auth Provider setup that will authenticate with our Github App (mainly handling the authorization process, which is the benefit of Named Credentials).
4. Create an app with a button to use our setup to talk to Github, using Apex (Salesforce side code).
5. Explore other integrations with the two systems, like REST APIs on the Salesforce side, and Web-hooks from Github.

Step by Step Actions to Build

Step 1.   Create a SF account

Obviously if you are reading this you probably have a Salesforce account.

What we specifically need is either a Production Org, or a Developer Edition Org,  one of which will be used as a “Dev Hub”.  The Dev Hub is Salesforce representation of all DevOps related SFDX items in your Org, like Scratch Orgs, and Packages.    In both scenarios,  the Dev Hub serves as the mother ship that hatch scratch orgs and spin up Packages.

If you are curious on Org Editions, check this link out… that should break down the different editions that exist besides the FREE one we are using now for this module.e

The Dev Hub I’m sure will become more abstracted out by various DevOps UI’s and Apps in the future, but for right now there are only a few settings and nothing else.  Much more on this in the future.

Regardless, we will use a Developer Edition Account, and although extremely limited it will allow us the functionality we need to link packages and create scratch orgs.  Click this link or the image to your right and sign up and store.

Pro-tip:  Given the unique requirement for Salesforce usernames, we can leverage a trick with gmail addresses where you can add suffixes to your email after a “+” sign and it will treat it as if it were the normal email.  For example:  me@gmail.com and me+developeredition@gmail.com would both goto me.com, and allow a way to handle multiple potential inbound emails in one inbox, and give you uniqueness.

Pro-tip2:   This is out of the scope of this tutorial but if you aren’t using a password manager like lastpass, or onepassword, I suggest it heavily.  It’s a good way to keep unique passwords managed via a browser extension and it will generate / save / manage them for you.  Worst case scenario is if every account you log into has “SomePass123” for all of them rather than a strong unique password per page.

Step 2.   Create a Github account

Github has a free version that I am going to tailor all of these modules with.  I just TODAY investigated paying for a Github account and it is fairly inexpensive for 1 user.  There are various levels to their pricing and products and you can find those here: Github Products.

For our intents and purposes we are going to stick with the free Github account, and it will instruct you to create an “Organization”.  Think of that like the company, and the children “Repositories” are what will actually be our package/apps/wiki etc.

Organization > User > Repo is the typical hierarchy of someones Account and repository setup,  with the more common thing being just the User > Repo.

Note:  you can change your username later, but beware of breaking things that may have your username/repo identifier hard coded in.

Still with me?  If you have made it this far it is within grasp for you to finish!  Take these new accounts and jump into the next step… Connected Apps in Salesforce and Github.

Recap:

• What we did– Creating a project management app in Salesforce to talk to Github and Pivotal Tracker to manage SF projects as a mock-project
• What we Created– Github Account and Salesforce Developer edition account and the process to create explained
• What is a trick for a long term takeaway- Gmail tricks like myemail+1@gmail.com and myemail+2@gmail.com both pointing to myemail@gmail.com and allowing multiple emails to appear unique funneling to one email.
• What should I have before moving on- A salesforce developer edition and a Github account without any access restrictions (default in newly created accounts OK)

If you have any questions let me know, otherwise I am going to keep plugging away with directions and hope it turns into something that is helpful to whoever is interested.   For the next item in the list to tackle with our accounts in hand:

Click below for the next post in the series, Configuring Salesforce and Github Communication

Resources:

https://github.com

https://salesforce.com

https://skitch.com