Custom Metadata - A better way to manage Skuid page/pageassignment/etc. migrations?

Hey Pat -

I’m with Zach in that cli tools are the best technical solution available currently.  Hopefully Custom Metadata based Skuid is in the future :slight_smile:

That said, you asked for a way to avoid using cli.  So while it wouldn’t be recommended, here’s a couple of thoughts.  I haven’t completely flushed these out in my head but I think they could be made to work:

1) Build a GUI based tool on top of the CLI tools.  This avoids your users having to use the CLI but functionally still uses it.  You could write the tool in any language you choose (Java, c#, etc.) and make it portable for different operating systems.  This would accomplish your goal of “clicks” for the users that are maintaining pages.  They would just need to remember go “click” in the GUI after they are done making changes.

2) Using a trigger/flow/process builder or some other SFDC feature, when a record changes, use an HTTP callout to commit that change to your VCS.  If I’m remembering correctly, bitbucket supports a REST API for various actions that can be taken.  You can leverage that such that when someone “saves a page”, it invokes a back-end process to commit that change to your VCS.  You could get really fancy here and use something like Mulesoft or Jitterbit (or some other ESB type product) that have orchestration capabilities to do more than just “commit” something.

3) Similar to #2, build a “sync” tool that takes data from Pages object and sync to your VCS.  You would build a queu’ing mechanism that would put a message in the queue indicating that someone saved a page, which org the save was in, what the record id of the save was, etc.  Then, your sync tool would poll for messages, grab the correct version of the page and sync to your VCS.

4) You could write a browser extension that the user could interact with.  The extension would “save” the skuid page and make callouts to the VCS, etc.

Again, just thinking out loud but hopefully this gives you some direction to potentially find a solution to avoid using CLI.  One thing to keep in mind with all the above is that some of them are better than others with regards to making the “save & commit to VCS” atomic - meaning that you are guaranteed to get your commit whenever someone saves.

Tthought of 1 more…

5) You could submit a feature request to Skuid to add extensibility to the Page Builder so that you can put your own “Save” button on it which would save the page and do the callout :slight_smile:

Thoughts on creating a Skuid page trigger to save the page to a static resource? This way it can be managed the same way as all other metadata in our SDLC processes. Of which no local repository or CLI is needed.

And what’s the downside of not using CLI?

I suppose that if all you’re doing with VCS is record keeping, then the trigger for creating a static resource would be fine. But you’re not going to be able to make changes to the resource and send it back to skuid that way (you could send them back to the resource in salesforce, but it wouldn’t impact the skuid page at all).

It would be easy enough to add code for the Skuid page builder to check for an update on open. I’d simply like a simplified approach for the strictly declarative devs. Which, again, is most Skuid devs.

Sounds exciting… but you want to actually change the page without opening the builder, right? It’s almost like you’re asking skuid to use your generated static resource as the page xml instead of the Page Layout text fields?

Also, Gearset look awesome!

I Am Jesus and I want a raise

Hmmmm … that would pretty slick, but I’m not sure it would be enough as there are other settings stored in other fields for the page.

Gearset is awesome for sure. Great fit for Skuid devs as it enables a declarative solution for source control solely based in the cloud. No CLI or local repos. Compare and deploy between Salesforce org, Local Repo and Source Control.

Zach and/ or Barry,

I’m deep into an implementation of SDLC/Agile Development. The solution we’re using is to use page packs as it’s easily accessible to understood by all the developers. Developers that don’t currently use any CLI tools I might add. Adding a process that makes use of CLI makes the implementation that much more intimidating to myself and our developers.

What I’m trying to drive at is that CLI is an imaginary line in the sand that many declarative devs aren’t easily/willingly going to cross. It’s a piece of cake for the likes of anyone with a software engineering background/career.

Skuid devs are commonly declarative devs who absolutely love what Skuid allows them to do sans any coding. Me clearly among them for sure.

So coming back to my implementation. Page packs is a solution that works with source control. Not ideal but it works. Any suggestions on how best to use page packs in this SDLC flow starting with the Admin (Skuid dev)?

Thanks,

Pat

I’m very interested in the outcome of this discussion! We’ve been fiddling with our deployment process, too.

Pat -

Happy to try to provide some thoughts on this but first, a few questions:

1) What are you goals/objectives of the flow you describe?  For example, are you simply trying to identify a path for deployment, are you wanting to be able to properly version, track and maintain your skuid pages (aka. source code), etc. 

2) What other items (beyond SFDC metadata) are you maintaining in version control (e.g. javascript, html, readmes, static resource bundles, etc.)

3) How many developers on the team?  

4) How many simultaneous “feature branches” do you typically have?

5) Who is responsible for merging feature branches to master and are you using pull requests?

  1. Yes to tracking Skuid pages in source code. BitBucket in our case.
  2. Here’s the list of what we are maintaining in source control.
  3. Currently have 5 developers on the team.
  4. Approx. 5 per sprint.
  5. I am responsible for the merging of branches to master and we are using pull requests.

Thanks Pat, this is helpful.  As with a solution for anything (e.g. C# vs Java, SFDC of Dynamics or Sugar, etc.), there often are multiple options so the more informed on the use case, the better a recommendation/path forward can be.

Given your answers above, I think Page Packs (PP) are going to going to create challenges for you, especially since one of your goals is source control management.  Page Packs are big long strings of “stuff” and therefore, from a VCS perspective, extremely difficult to “merge.” 

For example, let’s say that in Feature Branch 1 (FB-1) you make a change to Page A (P-A) and in feature branch 2 (FB-2) you make a change to Page B (P-B).  FB-1 and FB-2 then have a page pack of all the pages in that org.  If you merge the entire file in to master branch (MB), whoever gets merged last is going to win since unless you are extremely diligent/careful in isolating just the minor changes in the big block of text in that file, you’ll have to take the entire pack file itself on the merge which would result in losing changes from the previous merge.

There are some solutions to overcome this but they all would require manual effort.  For example, you could have a dedicated sandbox (DS) that is the only place you create the page packs from.  When FB-1 work is complete, the developer would login to the DS and manually update their page.  Same for developer when FB-2 is complete.  Then, you create the page pack from DS.  Alternatively, developers can communicate on a regular basis and say “Hey, Developers, I just updated my page, please update your org with the copy from my org for Page 123”

The goal of any SLDC should be to eliminate as much manual effort as possible.  Given that and the challenges from above with regards to trying to manage PP directly from each FB, I think you’re more than likely to end up in a scenario where you lose, break or forget a page.

In short, given your desire to use source control and version pages, I wouldn’t recommend using Page Packs.  If I was absolutely forced to using them, I would likely have a DS that would be the only “source” for generating the pack and each developer would be responsible for manually updating their page in the DS when they are complete with their work.

I know it’s now what you want to hear and I know CLI is a barrier of entry for your team, but if your goal is reliable version control, I do not see many other options short of the ones I mentioned in my previous post.

Let me know your thoughts.

My plan is to use named page packs for ds. The developer will update the module picklist with the fb name and that’s what will be used to track the pages in source control. Thoughts?

Not sure I follow you completely, sorry.  Can you explain step-by-step what you’re thinking?

Pat,

You might want to look at Blue Canvas (https://bluecanvas.io/) as another option for simple source control of Salesforce.

If you want to trigger an external system when a page changes, you can also look at Salesforce’s Platform Events.  They just released this in Summer 17.   It will create an immutable object for each change of any object.  It publishes this change on a ‘bus’ that you can have an external application ‘subscribe to’.  This link has a nice overview:  https://developer.salesforce.com/blogs/developer-relations/2017/05/first-impressions-platform-events…

As far as where you want to go with your setup to manage Skuid page changes in source control, I think you should go down the route of creating a Static Resource per Skuid Page/Assignment/Theme.  This will make it easy to merge individual items if needed and you can granularly move items from Dev to Full to Prod.  This means you’ll need a trigger to create/save the static resource and an invocable action that you can run from a Skuid button to pull all changes from the static resource just moved into a new org.  Note that in my ‘design’ you’ll need to watch the Static Resource for changes and have them committed to Source Control.  This is something that BlueCanvas does out of the box.

Thanks,

Bill

We create a sandbox, branch and when need be a static resource for the Skuid page(s) for each feature using Jira’s issue key to name them all. The process works similarly to Bills, but it doesn’t have the automation. 

Hey Bill. Can I see your setup works? What do you use to commit changes from the sandbox to the feature branch?

Blue Canvas looks nice. Not as far along as Gearset, but the continuous monitoring and deployment functionality could make life much easier.

Anyone care to develop the triggers and invocable methods that Bill suggested? Or at least get us started?

Pat - So at which point do you create the page pack?  How many Skuid pages does your org typically have? I’m still not following the entire process that you’re using, sorry.  Can you walk it through step-by-step?  For example:

1) Feature is requested
2) Issue gets created in JIRA
3) SCRUM occurs and feature gets assigned
4) …

Bill - BlueCanvas looks intriguing, thanks for pointing this out.  It appears that it automates some of the processes that we’ve been discussing here with regards to keeping org & VCS in sync - it’s the build vs. buy decision and I’m always a big fan of “buy” vs “build” :)  On the downside, the challenge with having a static resource for every page/assignment/theme is that you could quickly end up with lots of these.  In the last Skuid app I worked on, we had hundreds of pages.  Do you have any experience with using your ‘design’ in larger orgs with lots of Skuid pages?

Matt - (Note: Friday humor coming in 3…2…1) Probably not what you were thinking when you asked to ‘get us started’ but  here’s a start :slight_smile:

trigger trgPageToVCS on skuid__Page__c (after insert, after update, after delete, after undelete) {<br />&nbsp; &nbsp;&#47;&#47; create static resource for page<br />&nbsp; &#47;&#47;&nbsp; or publish event/make outbound call to 'notify' background process to grab latest page<br />}

Brilliant, @Barry! That’s exactly what I needed! :wink: