[WIP] some small tweaks

[kylemac]

• uses carrot as the default user (merged)
• sets default project to /var/www/default/current/public since this is a convention we use often

[notslang]

there still might be some places where this isn't configurable (because this is built atop a configuration where it was hard-coded), so I gotta take some time and test this

[notslang]

also, that needed to be updated in the readme

[kylemac]

@slang800 one additional thing I'd like for you to add to this PR is a basic index.html that says just says "by carrot creative" at /var/www/default/current/public.

[kylemac]

cool, that'd be great!

we follow this directory structure - http://nadarei.co/mina/directory_structure.html + the public folder of course. nginx always points to /var/www/<project>/current/public where current/ is a symlink to the most recent "release"

[notslang]

how come the releases are all in different folders? don't we use git to deal with this?

[kylemac]

releases are in different folders so that you can roll back easily (or step through them).

when we use something like mina or capistrano, it clones it to a tmp folder, moves it to a new release folder and symlinks it to current. this is described here (using the mina example) http://nadarei.co/mina/deploying.html .

the principles are mostly for ruby projects (not necessarily static) but the flow is still very helpful no matter what you're deploying

[notslang]

Yeah, I'd understand for ruby projects, but for static I'd expect ship to deal with pretty much everything.

Also, the public folder should be removed during deployment & all the stuff in it moved up to the top level of the project.

[kylemac]

I guess I don't like the idea of having different set-ups for different style projects when the only byproduct is an extra folder or two.

Even for some static projects, we still require a more heavy-duty deployment (like carrot.is for example) that right now ship can't handle (yet).

this salt-config doesn't need to concern itself with the diff release folders anyways - only that the releases dir exists to begin with.

[jescalan]

My plan was to have the ship vps deployer use multiple folders much like mina/capistrano. Being able to roll back a deploy is super important, you can't ignore that feature.

[notslang]

But does that mean that ship should follow that directory structure?

And what type of extra deployment does carrot.is require?

yeah, of course. but eventually I want the server to be fully autonomous

[notslang]

yeah, rolling back a deploy is important, but look how npm does it, for example - everything is managed with tags. no extra folders, just beautiful git & symver.

[jescalan]

I don't want ship to bank on you having git installed and set up on your server. I'd like for it to work with any server no matter what.

[kylemac]

carrot.is does a few things. it hits an API endpoint and passes the response to an nginx ERB template that then gets symlinked into place. it steps over a directory to see what needs special nginx rewrites and passes that to an ERB template as well. It also hits the cloudflare API to purge our cache.

here's an example of some of it's deployment tasks - https://github.com/carrot/carrot.is/blob/develop/config/capistrano/tasks/carrot.cap

the hope is that these can be moved to before and after hooks in roots so that roots handles the whole build process however -- just not the case now.

[notslang]

you don't need git on the server - it can just use git on the machine you're deploying from & copy over the site with sftp

[jescalan]

That means that you would need to have the public folder checked in to git and ship would need to make commits on deploy. We don't want either of these things for example, for a roots project.

[kylemac]

@slang800 we don't want to use tags to manage our releases. they are more transient then that especially when we're testing or staging things for clients

[notslang]

you wouldn't need the public folder checked into git because the entire public folder can be created from the source.

why would ship be making commits on deploy?

[notslang]

ok, how do you want to manage releases (given our current VCS)?

[kylemac]

@slang800 wouldn't that require roots or some other build tool to be present to compile the public folder from source (on the remote server)?

[kylemac]

@slang800 each new deploy is a new release

[notslang]

No, the build tool would be on the same machine that ship is running on.

Yes, but where do the releases get stored? What happens if I want to pull up an old release? Do I need to go into the production server? And what if I'm not someone who manages the production servers - I assume we're not giving everyone access to the servers, right?

[jescalan]

Ok, so in your last reply you are saying by tracking the source, ship could transform it into output. But the way that ship works is that it doesn't care what build system you are using at all or if you are even using one. If you want to ship a roots project, you run roots compile then ship public. So ship is not aware of what kind of compilation you are doing or if you are doing compilation at all, it just takes a folder of files and pushes it somewhere else.

What you are proposing means making ship aware of whether you are using a build system or not, and if so how to compile it. It also requires that you are using git on your project and understand generally how git works. This would be expanding the requirements needed to use ship and the complexity of ship quite a bit, which I don't totally see a reason for.

[kylemac]

@jenius @slang800 let's take this to slack.

[notslang]

tested it with the default user changed to carrot and it works... which is kinda surprising because I never checked to make sure that there weren't lingering references to slang till now.