Use Tugboat for development previews and possibly demos

Would there be any interest in having a current development preview of farmOS available “publicly” ?

TL;DR: I’ve set this up to track the 2.x branch from my fork. This preview should remain available at this link with admin/admin to login. Feel free to use. Right now it will rebuild nightly. :stuck_out_tongue:

I’ve been using Tugboat to share “previews” of some custom development I’m doing. It’s far better than doing screen shares and much easier than managing a separate “demo” server/site. Although core farmOS development follows a different workflow, I think it could still be a useful tool for our community.

Note that this would be a bit different than the Issue integration which only builds previews for merge requests. Instead, I’m suggesting we maintain and provide an up-to-date preview of the base development branch (we can use the same Tugboat config.yml for this!) If it works well we could link to our community preview in the farmOS README file. Always nice when projects have a big “DEMO” button, eh?

Perhaps the best part… Tugboat’s free tier is sufficient for hosting a single preview of farmOS! The free tier is limited to 2GB which is just enough for the required PHP and SQL containers (~1GB each).

Some thoughts…

  • A preview makes it easy to share the latest dev version with our less-technical community for testing and gathering feedback.
  • While doing core farmOS development I find myself jumping between my feature branch and the base branch to see what my changes look like or reference how something worked before. Having a separate “preview” of the base branch available at anytime would be helpful in these situations.
  • Tugboat previews can be configured to automatically rebuild on a schedule (daily, weekly) and/or rebuild with the click of a button. This deletes all data from the DB. For a “public” preview it might be nice to automatically rebuild, but for “private” development it’s nice having control over this. What would be best for a shared “public” preview? :thinking:

Using Tugboat for demos

Tugboat could also work great for providing demos of farmOS. When building the preview’s DB container it’s possible to import from a DB dump which is included in a “base preview” snapshot. Later previews that are built from this base preview can make changes on top of this snapshot without affecting the base preview itself (what’s cool here is that the base preview’s snapshot size is only counted once towards the Tugboat tier’s storage usage… a base preview might be 2-3GB, but later previews are only 100MB each)

So… what this means is we could build up “demo” farmOS sites, export the DB, and create a base preview from the DB dump. When creating a new demo, users are free to add/delete/modify things, but it can easily be rebuilt back to the base preview on a regular basis.

Backdrop CMS actually uses for Tugboat with this approach for these “demo sandboxes” highlighted on their home page. Users can spin up their own “private” ephemeral demos - it’s quite cool! I imagine this would start to cost some $$ since there is a potential of many previews to be created, but perhaps even just $20/month could go quite far.

It would be really neat if users could choose from different demos matching their use case: “Livestock demo” vs “Crop planning”, etc…

Of course I don’t want to discourage use of the Farmier free trial :wink: There are perhaps some overlapping but also different use cases with demoing farmOS. It’s nice to see placeholder data, but also nice to start from scratch and have that carry over to a hosted instance.

1 Like

I love this idea!

what this means is we could build up “demo” farmOS sites, export the DB, and create a base preview from the DB dump

I also wonder if our previous thoughts around a farm_demo module (or perhaps a set of modules) would make this easier? And also be useful for other purposes…

(Context: Example Data for FarmOS - #13 by mstenta)

Yeah they could probably help! If these modules were in their own repositories they could have their own config.yml to create separate previews that could be used for integration tests.

A general challenge seems to be making demo data that is always relevant to the current time… (eg: so the demo always has an “planned” log for the next day). The DB dump might not be very helpful here, but maybe a well designed build process could accomplish that… or perhaps it would be easiest to parse a DB dump and offset all the timestamps before importing again… :thinking:

Mm yea, or perhaps simplest of all: just a hook_install() that creates assets and logs - similar to the way automated tests create mock records. Or maybe a combo of default_content defined in YML and a hook_install() that updates the timestamps…

1 Like