We would love to move to Custom Metadata for Pages, Page Assignments, Model Services, Model Service Adapters and other things. It’s probably something we’ll be exploring in the next Major Release after Banzai. The biggest issue right now is their lack of support for any long text. So we won’t be able to move Pages until something like that is supported.

There are 3 major reasons why we cannot use Custom Metadata types yet for Skuid, much as we would like to:

1. No Long Textarea (LOB) fields — Skuid Page XML metadata is stored in a combination of several Long Textarea fields on the Page object. Because Custom Metadata types do not offer Long Textarea fields, we really can’t use them right now as a viable alternative for storing Skuid Page metadata.


2. No Relationship / Lookup fields — the Skuid Page Version and Page Assignment objects have lookups / master-detail relationship fields to Page records. And with Banzai, the Page object has a Lookup field to Page, to allow for Master Page functionality. Custom Metadata Types do not have a concept of Relationship fields. 


3. No Triggers on Custom Metadata types — the Page and Page Version objects have trigger logic that is essential for their functionality. Custom Metadata types do not support triggers.


4. No DML support on Custom Metadata Types — currently we use DML to create/modify/delete Skuid objects / custom settings. Custom Metadata Types can only be edited with the Metadata API. This presents substantial migration challenges for our existing codebase, including creation / updates of records from our Post-Install Apex script, modification of pages from the Skuid UI / Composer… it would take a lot of complex migration work.

Thanks for the insight Ben/Zach, makes sense why moving there now isn’t possible but glad to hear that it’s a potential future direction once MDT matures.  Having this in place would make things so much easier in terms of deployment management, version control, etc.

I’ve read the roadmap includes Relationship/Lookup Fields and APEX DML support, hopefully LOB & Trigger support will be included as well.  Though not ideal, I could see ways to overcome the lack of trigger support but lacking LOB would be make things difficult, or at the very least, extremely messy.

So I’ve been setting up Source Control in BitBucket. One thing that would make this setup much better would be if Skuid were to use Custom Metadata.

I’ve looked at the list of the 4 issues provided and it seems all but “No Triggers on Custom Metadata types” is now available. Is there any update on this? A workaround maybe?

I know that static resources can be used to commit changes to source control, but the issue with this is that there is still a very manual process to ensure there are no overwrites. Can’t very well pack everything into one static resource, so steps must be taken to pack changed pages into their own static resource.

Any tips and tricks anyone would recommend on this?

My current strategy is clone the Skuid Page into new Record/Named version and update Visualforce. Allows for one page pack everytime.

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

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?