...now what?

[xendk]

I was pretty excited to see this project, but I'm a bit unsure about the direction.

I see you've added a roadmap, which mentions some interesting possibilities, however I'm missing some clear short term goals.

I don't know if a FAQ might help here, but here's a few questions:

• Any ideas for adding a hostname to the main container, so after enabling an environment one can immediately go to .dev and see the site? I figure some messing about with /etc/hosts could do it.
• Syncing of site data. Sure, drush can do it, but getting Drush to sync database and files between two environments are non-trivial. Also populating the site initially.
• And basic configuration of Drupal? Having to edit the settings.php is a bit old-school
• Container configuration. One advantage of using Docker is the ability to ensure the exact same versions of PHP/Apache/NginX/MySQL/MariaDB/Varnish. Editing the docker-compose.yml is one way to influence this, but it should be clear whether that's accepted usage. Alternatively, some other way to hook in there.
• Naming. "App" and "Environment" is a bit confusing at first. Might be solvable with good documentation and help, but I tend to think "Project" and "Instance" instead.

I think outlining some clear short term feature goals would be good. It would give people interested in the project something obvious to work on rather than having to think up something and hoping it will be accepted.

[jonpugh]

Thank you so much for your interest. The ripple that the one tweet created was unexpected.

I am going to make it more clear that this project is in the very early stages but, it does indeed have a very clear vision for what it is going to do. I can see you have some idea of where this is going.

I've started out by identifying the next immediate steps in other issues in this queue. Most of which you've mentioned right here!

adding a hostname to the main container

If you run the terra url-proxy:enable command it will start an nginx-proxy container that can be used to route multiple domains per host.

To make this more robust I created the following three tickets:

• Ensure the URL proxy container is running when displaying URLs for environments. #20 Ensure the URL proxy container is running when displaying URLs for environments
• Allow adding of domains to environments #18 Allow adding of domains to environments
• Make Environment DNS setup automatic #19 Make Environment DNS setup automatic

Syncing of site data.

We are going to use the "drush" container as an SSH endpoint for users. Hopefully we can get that container to be the main interface into the database.

See the repo https://github.com/terra-ops/docker-drush/.

I am going to be working on this in the next few weeks.

Container configuration

The aim is to build terra to be as flexible as possible, to the point of being able to swap in your own docker-compose.yml entirely. (#21)

I'm not exactly what the best way to allow tweaking of configuration, yet. Likely it will be the setting of ENVIRONMENT_VARS, and figuring out how to pipe those to config files in the containers.

"App" vs "Project" vs "Instance" vs "Environment"

These are all hard things to name, but I've gotten pretty accustomed to the metaphor of an environment thanks to devshop. I would be open to return to "project", which is what devshop uses. I thought that "project" might be overused, but I could be wrong.

Always open to hear feedback from others on this. If people feel that we should change the name of something, please argue why you think it's a good idea.

I do think "Environment" is best here, because it is more conceptual. An environment is a conceptual thing. An environment could fit on a server with many other environments, or an environment can be 100 servers. An environment can be a dev site on pantheon, or it could be your localhost.

An "environment" represents everything needed to sustain a living website.

Clearer Documentation

I've added more to the README and a new docs page describing the current container layout at https://github.com/terra-ops/terra-app/blob/master/docs/containers.md.

I am speaking on Terra at NYCCamp in two weeks, so I am working hard on gathering all of the plans together and documenting and announcing the vision.

I'll be coming out with a blog post soon that announces the overall vision.

The most important thing for the project is to know you should keep giving your feedback. I want to kick this off as a collaboration from the start.

I'm also going to do my best to remain truly agile about this and prioritize our tasks as user stories that are derived from feedback from the community.

So your feedback is really appreciated.

Thanks!
Jon

[xendk]

Naming

I admit that "instance" was a poor choice, it was just something that popped up in my head. My real beef is with "app", which I think is being overused. But rather than "project", I'm more in favor of "site". Unless you're using terra for something really weird, what you're making is basically a site, regardless of complexity so why not call it that?

Another thing: How about tests? Besides being all the rage nowadays, I've grown rather fond of using tests both TDD/BDD (https://github.com/xendk/proctor/blob/master/features/build.feature) to define expectations and classic testing (https://github.com/xendk/proctor/tree/master/features) to ensure that I don't break existing features.

I'm especially a big fan of the TDD method which really shines when don't have to repeatedly restore the input state in your ad-hoc test evironment. And being able to run the full test suite after major refactoring is a godsend.

[jonpugh]

I'm going to leave the naming debate out by the bike-shed, if you don't mind. These things we are building are web apps, and terra could be used for hosting any kind of "app", even the backend for native apps. I don't want to limit ourselves to building websites.

Regarding testing, absolutely yes. Making testing easy is one of the big four user stories for terra.

The command will be called terra environment:test. The tests to run will be contained in your app's .terra.yml file, so that you can define your own set, including behat, PHPUnit, etc.

I plan on implementing testing with the next few weeks.

Proctor looks interesting! Thanks for pointing it out.

[xendk]

I'm sorry you see it as bike-shedding, but I do consider terminology to be rather important, as it's the first thing users get confronted with, even before trying the app.

We're obviously coming from different places, as I don't consider the sites we build in our company "apps", even though they're pretty complicated and often communicate with one or more external services. Neither does our customers, and I'd suspect they'd be rather confused if we started talking about "their app", especially those who also have a mobile app.

Our own backgrounds aside, I think you risk alienating some of the users that could get the most benefit from terra: the small scale site builders. The ones that's churning out a lot of small, simple sites. I doubt they consider their output as apps rather than sites, the fact that any CMS driven sites can be considered an app notwithstanding.

While site and app are either end of the spectrum, "project" covers both, even if it is a tad generic. It also have the advantage of being familiar from a lot of apps which also use the concept.

Regarding tests, I'm sorry that I didn't make it clear that I meant testing of terra itself. Testing of what's inside the containers can be adequately handled outside of terra if need be. But when terra grows in complexity, a decent test suite will ensure that new development doesn't break any existing feature. It's a great peace of mind when refactoring.

Just noticed I linked twice to proctor, I meant to use Bandaid as an example of "classic" testing (https://github.com/xendk/bandaid/blob/master/tests/bandaidTest.php). Actually, the tests of Deployotron (https://github.com/reload/deployotron/tree/master/tests) are even more vital as the cost of failure can be rather great (messing up a customers production site).

FWTW, I'm experimenting with converting Bandaids rather unreadable Drush tests to Behat in the hope they'll get more manageable. Wanting to move it from Drush to Symfony Console is also a factor.

[jonpugh]

Thanks for your input! I think you've started to win me over.

I am always open to changes. My other big project, devshop, has been using "project" for years. I thought that maybe "app" would make more sense when opening it up to non-drupal stuff, but perhaps you are right.

"Project" works for devshop, why change it?

If you have time, I'd be happy to review (and would likely merge) a pull request renaming "app" to "project".

As for having internal tests for terra, 1000% yes. I want this project to folllow all modern best practices , including PHPUnit tests, Behat tests, tests for the containers themselves... as much as possible.

I just don't have time for everything, so i will reiterate my encouragement of the community to please help! 😧

There's a lot to do!

[xendk]

I'll do a rename PR. Don't know if I'll have time before going on vacation though.

[jonpugh]

We've discussed it, we're going to change "app" back to "project".

Thanks for your feedback, @xendk!