Remove deployment directories

[abea]

The A3 boilerplate includes the scripts and deployment directories with the kind of deployment files that we've used in 2.x. Or at least those that we on the core team and our close colleagues have used.

So there's the question: does everyone who starts an Apostrophe site need these? Even if they're helpful, should they be default? It would help to know more about how people who aren't on the core team or at P'unk Avenue deploy Apostrophe sites.

stagecoach is super useful and easy once you know it, but it's a specific deployment choice. The deployment directory structure and file naming is at least partially tied to our use of that utility. Ultimately that utility should probably be removed from the discussion of what is included in the default boilerplate, though.

The sync scripts in the scripts directory are useful without stagecoach and they do use that same deployment profile format as stagecoach (not by accident). Syncing data is a pain in the butt, so it could certainly be useful to have those at hand... but you don't need them.

Part of this is a question of what the boilerplate is: an MVP model of an Apostrophe app or the recommended version of a basic Apostrophe app. There's value in the latter, but the default should probably be more of an MVP. That would probably suggest that these deployment files are unnecessary. So getting rid of them is suggestion one.

Suggestion two is that the CLI tool eventually do all this work. It should walk people through some of these decisions. "Do you want to included recommended deployment files?" If yes, include those two directories with a README in one or both explaining how they work.

[boutell]

Yeah, this here's a convo.

…

On Mon, Mar 22, 2021 at 4:24 PM Alex Bea ***@***.***> wrote: The A3 boilerplate includes the scripts and deployment directories with the kind of deployment files that we've used in 2.x. Or at least those that we on the core team and our close colleagues have used. *So there's the question:* does everyone who starts an Apostrophe site need these? Even if they're helpful, should they be default? It would help to know more about how people who aren't on the core team or at P'unk Avenue deploy Apostrophe sites. stagecoach <https://github.com/apostrophecms/stagecoach> is super useful and easy once you know it, but it's a specific deployment choice. The deployment directory structure and file naming is at least partially tied to our use of that utility. Ultimately that utility should probably be removed from the discussion of what is included in the default boilerplate, though. The sync scripts in the scripts directory are useful without stagecoach and they do use that same deployment profile format as stagecoach (not by accident). Syncing data is a pain in the butt, so it could certainly be useful to have those at hand... but you don't *need them*. Part of this is a question of what the boilerplate is: an MVP model of an Apostrophe app or the *recommended* version of a basic Apostrophe app. There's value in the latter, but the default should probably be more of an MVP. That would probably suggest that these deployment files are unnecessary. So getting rid of them is *suggestion one*. *Suggestion two* is that the CLI tool eventually do all this work. It should walk people through some of these decisions. "Do you want to included recommended deployment files?" If yes, include those two directories with a README in one or both explaining how they work. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#12>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAH27MNEPZX52ZFNDAUAXTTE6RPPANCNFSM4ZT2LFEA> .

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[abea]

That's the idea!

[boutell]

We do need to maintain stagecoach files suitable for A3 somewhere, for now. But a3-demo has 'em, and it's basically for internal use. So that's covered. These files are rather handy guides to what actually has to be done during a deployment, no matter how it's carried out. But we could cover that through documentation instead.

…

On Mon, Mar 22, 2021 at 5:04 PM Ben Loeffler ***@***.***> wrote: My vote is for *suggestion one*, for now. We have a lot of ideas around how to leverage the CLI in the future, but we're not quite there yet in the roadmap. I think suggestion two is best addressed during that project. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAH27P3PS7LWRFZP5XQ5UTTE6WETANCNFSM4ZT2LFEA> .

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[abea]

Good points. I do think that explicit documentation, or a "how to" with copies of these files or links to a demo site would be better. Right now they lack context, which is sort of true for the A2 boilerplate as well.

[localghost8000]

My vote is for suggestion one, for now. I think suggestion two make sense and is a good direction to define, but its lead by suggestion one and will need to be planned out on the roadmap.

[abea]

Yeah, I the CLI bit would happen whenever other CLI work is happening.