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

Pat, any reason why you’re not using Skuid Grunt or Skuid CLI (https://github.com/skuid/skuid) to do source control on Skuid Pages? This is our recommended approach. When doing active development on Skuid Pages, I would definitely use one of these two tools instead of Page Packs.

Looking to avoid using any command line as it’s far from user friendly when client declarative developers get involved.

Additionally, it’s not doing a commit to a branch so a pull request would not see the differences. Code cloberring will occur using only this CLI.

Hmmm … I suppose one could stage and commit the skuid pages to the branch and subsequently use Source Control this way. Not ideal as most declarative devs are not going to easily take this on, which is to say most Skuid devs are not going to.

This doesn’t fit the whole Skuid mantra of clicks not code (CLI) though.

Any suggestions on how best to manage Skuid within Source Control with clicks not code?

We’re using Jira, BitBucket and Gearset to manage Agile Dev, Source Control and Release Management. We can click to create branches, commit changes, pull request, merge and deploy all from the cloud. Only wrinkle is Skuid Pages as they don’t transfer via metadata without Static Resources and this would additional steps in order to commit to branch and deploy to Salesforce. ie. pack and unpack.

If we had custom metadata, then everything would be a single step for each operation in the SDLC.

Thoughts?

It’s been an uphill battle, but we’re doing everything on the command line now using bitbucket with skuid-grunt and grunt-ant-sfdc.

A clicks-only approach would definitely make it easier for new hires to get working quickly.

How about mirroring (auto saving) each Skuid page, page assignment and custom theme as a Static Resource? That way none of this malarkey about command line needs to be done.

Seems too simple to me, but can this be done?

More and more tools allow for simplified SDLC processes. We’re using Gearset and BitBucket, so we can do everything from the cloud. ie. no local repository or command line.

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?