0

My basic question is: if I repeatedly copy a Rails app, so there are many generations of the same repo (i.e., various iterations of a Rails app's directory and files), what do I need to do to ensure that the server runs normally and avoid major issues?

I'm writing a learning app that drills the user on programming tasks. Right now it supports only single-file tasks. I want to add support for multiple-file tasks next, involving HTML/CSS/JS and Rails tasks (e.g., "add a model that does such-and-such" or "add a Minitest test for such-and-such feature"). The user will be required to edit the Rails code directly, and my app will then automatically run the server and show the results. After each question is answered (i.e., each task is performed), my app will migrate down the database automatically as necessary and copy the repo anew from a tarball--basically, preparing the stage for the next time the user tackles the task. (Well, I hope it's a good idea.)

Since Rails apps are so big and complex, of course it's not feasible to build and add a separate Rails app for every question. Instead, I will have many questions/tasks that are based on the same repo (installation). After each question is answered (i.e., each task is performed), the database will be migrated down as necessary and the repo copied anew from a tarball. So far, so good? (I anticipate problems using Git to do this...so I would just use Minitar for this.)

But of course I will have to make other versions of the same repo (using the same database, or maybe a copy) when I make other clusters of questions. For example, I might want a bunch of questions/tasks related to using AJAX in Rails, and for that I need to prep an installation in various ways. But if I'm just building on a copy of a previous repo that has its own tasks, will the copying process cause issues for the later repo and its tasks?

I have done some testing. I have already confirmed that if I simply execute cp -r repo1/ repo2/ and then run rails s in repo2, the server for the latter starts normally. While data written in repo2 does not appear in repo1, I can't create an identically-named model (which is a little puzzling). I imagine this might be a problem for some questions--i.e., I don't really want them running from one and the same database for all repos, even if later database versions are based on earlier versions. So whenever I copy a repo, I guess I'll want to make a copy of the database as explained here. Sound right?

Is there anything else I'd need to do in building this feature that would prevent issues related to repeatedly copying different iterations of the same repo (and database)?

globewalldesk
  • 544
  • 1
  • 3
  • 18

1 Answers1

3

I think you're making it more complicated than it needs to be. This can all be done in git by leveraging git feature branches, e.g. question-1, question-2, for each derivation and combining that with the rails rake database tasks, e.g. rake db:drop, rake db:create, rake db:migrate, rake db:seed, to ensure your database is bootstrapped properly for each branch.

An alternative approach could be to add SQL dumps of your final database state to each feature branches and load them via a rake task to bootstrap your database to your desired state.

engineerDave
  • 3,887
  • 26
  • 28
  • I was wondering if something like that might be possible. But these branches would all be inside of the big Revuu (my learning app) repo. Wouldn’t that cause git issues? Ah, I am reading about submodules. – globewalldesk Oct 30 '18 at 16:36
  • FWIW this is how we (and most shops) develop our apps with long lived feature branches at my work. It's a fairly common pattern and is part of why git exists. As long as you don't put a ton of large binary files, eg videos, git shouldn't have any problem keeping the size small. It's best to trust git to do the optimization. – engineerDave Oct 30 '18 at 22:29
  • you shouldn't need submodules to do this either FWIW. essentially practice YAGNI (you ain't gonna need it) and don't prematurely optimize your workflow. – engineerDave Oct 30 '18 at 22:30
  • What I have in mind is that I'd be regularly pushing the app (Revuu) code, while regularly making and updating branches of various repos contained within the big Revuu repo. If a subdirectory of Revuu is made into a Git repo, and then various branches of are added and checked in, wouldn't there be potential problems (not sure what) when I go to push the latest big Revuu changes? And suppose someone wants to use my data (in a future `data/repos`). Will they be able to use my Git branches too? – globewalldesk Nov 01 '18 at 00:37
  • 1
    submodules are a bit of magic territory but IIRC they're essentially just pointers to other repos SHA hash at the point you check it in, then git recurses through and initializes it, checking the sub repo out locally. AFAIK nothing of the other repo is actually contained in the repo they're added to so I think you'll be fine. – engineerDave Nov 01 '18 at 20:09
  • 1
    Your solution, @engineerDave, worked perfectly. The feature is in production! – globewalldesk Nov 22 '18 at 14:30
  • 1
    Congrats @globewalldesk! – engineerDave Nov 22 '18 at 17:56