What are the best practices for versioning / deploying an OctoberCMS site? In my case I've got a custom theme as well. Should I version the entire install, or just the theme, or both?

Also, I'd love to be able to use a deployment tool like Rocketeer to deploy either the theme or an entire site.. but I've ran into a couple problems so far. If I version the whole install (with git), when I push up using rocketeer, the plugins folder is empty.. This is because I have that folder in the .gitignore file... since it doesn't make sense to version other people's code / installed plugins. If anyone has any suggestions, they are very welcome!

On the other hand, if I were to version just the theme, I would run into issues when deploying with rocketeer, because of its folder structure. It has folder structure like:

releases
current  // symlinked to latest folder in releases, and where you point your vhost
etc...

Pretty new to octoberCMS and just trying to make my workflow from development => deployment as smooth as possible. Thanks for any suggestions or help!

Last updated 10 years ago

Only the theme is needed to be version controlled and deployed, with the exception of any custom [private] plugins. The best approach is to simply use git.

@daftspunk thanks for the reply. I already version things with git, but it's not really meant as a deployment tool. Surely, there has to be a better way? Embracing deployment tools like Rocketeer or Capistrano really helps automate deployments and I'd love to make it work smoothly with october. Anything else I could try? Using anything else for deployment seems like a step backwards now...

@406digital,

I was looking into rocketeer as well, but I've also started using docker a lot lately (https://www.docker.com/). This pushed me towards dokku (or https://github.com/dokku-alt/dokku-alt, this is slightly more advanced version and very active). This allows me to push my git repo and it will build a server on the fly. All my server tweaks (php.ini, nginx.conf) are stored in my octobercms git repo, so it is also tracked.

If you want to test out dokku, let me know. I've spent some time with it and know a bunch of its quirks that aren't immediately apparent looking at its doc's.

The problem with this approach (and rocketeer/capistrano/etc...) is http://octobercms.com/forum/post/vcs-and-the-cms . The fact that the end user may change those files withing the CMS backend on the server. This forces us (developers) to need a way to pull/get/download changes from the server. I've not come up w/ a perfect solution for this, but have an idea. I need to test it, but if it works well I'll share it.

@that0n3guy -- thanks for your reply! The link to that other post is interesting too, hadn't seen that one. Deployment was something initially confusing... but I wasn't even aware of 'Projects' on the octobercms site then. Now that I've used october a little bit more, I see the whole picture. :) For now I've resorted to simply cloning my theme's repo onto my server... Not as automated as I'd like, but at least I can ssh in and pull / push changes from the live server and then pull them down onto my local. Perhaps we should make an October-specific deployment / sync tool that utilizes git behind the scenes to sync things up? Something to think about at least.. thanks again!

My personal development cycle involves checking in the whole project (ignoring storage/ directories).

I develop locally with Vagrant and Laravel's Homestead. Commit and push to my remote git repo. Then use DeployHQ to deploy all the changed code to the server. If I change a plugin, I do it locally. If I upgrade october, I do it locally. The one "gotcha" is to remember to run any migrations that are run with an upgrade or install.

I work like andrew as well (I exclude vendor folders as well though, then have composer install run on the server. If I change something, it happens locally. Even october upgrades. I want to be able to push to testing server (teamcity for now, but this is often skipped on small projects), staging, then production.

@andrew, how are you handling the CMS changes to themes directory? (ie http://octobercms.com/forum/post/vcs-and-the-cms) Are you just not allowing clients to use the CMS section of the backend. If thats the case, are you also not using the static pages plugin?

Thanks for your contribution @andrew. I'd prefer to not version plugin code and other outside code in my repository. Why version that stuff when you can attach a project (from octobercms.com) to each install and it will sync everything (except the theme, which is the only thing in version control) for you?

@406digital, you version it b/c:

• you want your local, staging, production to all be the same version of october/plugins. If your installing october on the server after installing it on local, you can't guarantee something hasnt changed.
• you may find that you need to hack a plugin, so you don't want october to install it b/c you've forked it and its not the same.
• you create private plugins that you don't want in the market (ie, won't be installed w/ octobers project thing).
• easy to see what's changed on october and plugin updates
• why not... I don't know the downsides.

@406digital

What @that0n3guy said. Same reasons. The biggest for me is the first he listed. Making sure it's the exact version that I have tested and developed against.

Also on vendor folder, I ignore that one as well. Good to call out, @that0n3guy.

I suppose one downside is ease of upgrade. Instead of just throwing caution to wind and upgrading live, WordPress style, following a proper development process is worth it in my opinion.

In the case you haven't forked a plugin, the theme is all you need to version and should work with any install.. it's pretty easy to sync plugins with an October Project. If you have forked a plugin, it might make sense to version the whole install, but it still doesn't make sense to version everything else inside the plugins folder... it's like versioning your vendor folder! In that case, utilize composer to install the forked version by specifying its repo in composer.json. Check out this section of the Composer docs for info on how to make composer install the plugin to the proper directory. OctoberCMS themes, plugins, and modules are supported.

Doing it with composer allows you to only need to keep your own (private) plugin code under version control. This way, there's no need for versioning the plugins directory as a whole (assuming you use an october project too!). You may prefer to keep it all in VCS but i'd rather not track the extra files. @daftspunk's reply was spot-on, and I assume his response relates in part to OctoberCMS being listed here.

Last updated 10 years ago

@406digital I still disagree, but it's really a work around for an issue with the October Project. There's no way to know that the version that you have in your project locally is the same version that is deployed to your server. Unless I'm missing a part of the settings for October Project, but I don't see that anywhere within the account admin for October Project.

The project just allows you to keep (non-private) plugins in sync across multiple environments. Keeping public plugins in a VCS just seems wrong when you could utilize composer to pull in those dependencies (and composer.lock to ensure the version's the same). I know I'm not alone in wanting to keep outside code to a minimum in my repositories. Not only does it bloat your repo, it just feels like a bad practice. Disagree all you want, but I'll stick to versioning the theme only as @daftspunk mentioned.

As far as keeping your theme in sync... using git to clone the repo to the production server has served me well. If you wanted you could create a new (git) remote to push directly to from your local machine.

Last updated 10 years ago

@406digital,

I see the logic of thinking of the plugins folder as vendor. But it has a couple issues at the moment:

• You can't specify plugins in your composer or any other version controlled file (that I know of, I guess you could use the scripts section... thats an idea).
• There is not plugin repository reference thing like composer has (so your example doesn't work since plugins aren't composer packages).
• With October's current project functionality, you can't specify plugin version
• october doesn't have a version, so you cant specify that right now in composer.

Those bottom 2 alone are enough to cause problems if you don't version the whole thing. I've already had an issue w/ it once. The version I was using was fine... the updated one was broken. If I didn't have it in VCS, I would have had a broken install for 2 days OR wasted hours debuging core october code myself.

I currently don't use octobers project functionality ( I stoppped using it) because you can't delete a plugin from a project.

but I'll stick to versioning the theme only as @daftspunk mentioned.

What about everything in the /apps folder (environtment based database config files, etc..). These should be in VCS as well.

• October is in beta, you've got a valid point with the dependency not being able to be locked down, but you could lock it down to a specific commit in composer.json if you're worried about breaking updates.
• You should be able to specify private repositories in composer. Also check https://getcomposer.org/doc/05-repositories.md#package-2.
• I prefer to keep sensitive configs out of my repositories.

I agree with both of you it could be convenient to do it your way, but (especially once october is stable), keeping all that 'junk' in your own repo if you don't need to seems far from ideal. I'd love to hear @daftspunk 's opinion more in detail on all of this.

Last updated 10 years ago

@andrew you've had no problems doing things the way you do? I was doing this (using Homestead) and had a proper ache trying to deploy to a staging server. Ended installing October on staging server and manually copying across custom plugins and theme. Be interested to know what you do about any live server CMS changes that occur, perhaps that's not an issue for you.

All of this aside, I still struggle to use a deployment method if changes are going to be made in the CMS backend on the server WITHOUT logging into my server and commiting/pushing changes before doing more local development.

@adam If you start with the october repo and do not use the installer I haven't had an issue with this. When I attempted to do it using the installer, that was a HUGE pain. That said, the installer wasn't meant for this type of deploy.

@406digital When the version numbers are locked in the October Project I will be using that. But as-is I just can't. It's beta, as you mentioned, and things can easily break. I don't want to have code that is essentially a full copy of a public repo.

So in short, I don't plan on keeping the plugin directory in my repo forever. However, in the short-term I am.

@adam, I've never used the web installer and not had any problems. I've always installed with composer and not had issues either.