Jump to content

Deployer recipe


Can
 Share

Recommended Posts

Thanks to a new "community" member I just started using git and deployer for my main project happygaia.com it's soo nice and clean and million times faster to publish a new feature, fix or whatever..I'm still in development or more bug fixing phase so I haven't actually deployed to live stage yet but local to staging works like a breeze so far

I already separated processwire deploy logic from project stuff to start a dedicated processwire recipe which looks like this so far

<?php
/**
 * Deployer ProcessWire Recipe
 * Version 0.0.1
 */
require_once __DIR__ . '/common.php';

// ProcessWire shared dirs
set('shared_dirs', ['site/assets']);

// ProcessWire shared files
set('shared_files', ['site/config.php']);


/**
 * Symlinking assets and config.php from Deployers shared folder
 *
 * @note You have to put those files manually into shared folder before first deploy
 *  To run this task automatically, please add below line to your deploy.php file
 *     <code>after('deploy:symlink', 'processwire:symlink');</code>
 */
task('processwire:symlink', function() {
    run("ln -s {{deploy_path}}/shared/assets {{release_path}}/site/assets");
    run("ln -s {{deploy_path}}/shared/config.php {{release_path}}/site/config.php");
})->desc('symlinking assets and config.php from shared folder');


/**
 * Main task
 */
task('deploy', [
    'deploy:prepare',
    'deploy:release',
    'deploy:update_code',
    'deploy:symlink',
    'cleanup'
])->desc('Deploy your project');

after('deploy', 'success');

As you might note the processwire:symlink task won't run automatically, you either call it manually or like mentioned in the phpdoc you hook into the deploy task and put it e.g. after deploy:symlink

Reason for processwire:symlink is that at least happygaias assets folder is quite huge and it's not part of my git repo so it's not being deployed each time instead it gets automatically symlinked from deployers shared folder
Side note: Images (for now) only being updated from live page so no need to upload in deployment process..
Nearly forgot to mention that it's not only about assets folder but site/config.php, too. So config.php is not part of my git repo so I place it in deployers shared folder once and it get's symlinked (like with assets)

The plan right now is to "just" keep databse of live site intact (more or less) after I switch live to new version it'll update because of new pw version and module versions of course and I have to tweak some minor changes, manually e.g. exporting/importing templates but that's fine for now
I might look into AutoExportTemplatesAndFields module soon as it sounds really nice

I still have to figure some deployer things out, but as mentioned it seems to work fine for now

Okido that's all for now, questions, comments, feedback everything is welcome and appreciated

Uh it would be nice to get more ideas and testing whatever for the recipe so I could post it to the deployer repo soon ;-)

  • Like 8
Link to comment
Share on other sites

There is no need for processwire:symlink task. Just use the built in deploy:shared task instead:

<?php
/**
 * Deployer ProcessWire Recipe
 * Version 0.0.1
 */
require_once __DIR__ . '/common.php';

// ProcessWire shared dirs
set('shared_dirs', ['site/assets']);

// ProcessWire shared files
set('shared_files', ['site/config.php']);

/**
 * Main task
 */
task('deploy', [
    'deploy:prepare',
    'deploy:release',
    'deploy:update_code',
    'deploy:shared',
    'deploy:symlink',
    'cleanup'
])->desc('Deploy your project');

after('deploy', 'success');

And not sure config file has to be shared. Of course it is bad practice to store you db credentials in the VCS, but this file is quite essential for the PW site.

  • Like 6
Link to comment
Share on other sites

Interesting thanks for sharing! Even shorter :D
And now I get the use of setting shared dirs/files haha :D

So if not in the repo and not shared, how else? Uploading with each deploy?

So you're using deployer, too?

Update: Have to investigate this further as it's not working for me for now. After trying this out the staging page is unreachable telling me there is no config/installation file..

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

Okay I figured it's probably my fault but couldn't try it until today..

So @Ivan Gretsky's recipe is working fine..some might already know, but for the shared files/dirs to work you need to set up the correct file structure within shared directory, so you're shared folder needs to look like this

-shared
	-site
		-assets
		-config.php

 

  • Like 3
Link to comment
Share on other sites

@arjen in this recipe situation you store the actual config.php and the assets folder there

I'm doing it like this because I have all this excluded from the git repo, so they won't be deployed, that's because some people don't like to store credentials in git (sounded legit so I'm doing the same) and my assets folder is quiet huge already and I had it already on the server so I just copied it over to the shared folder of deployer
then the recipe will symlink them to your current release when deploying

if you don't like it you can just omit this recipe, include only common.php from deployer in your deploy.php and depending on your needs just define servers and the deploy task/chain and maybe add some custom tasks..

Let me know if you need help

Link to comment
Share on other sites

It is better to deploy all the shared resources after the initial deploy with deployer script, as all the folders needed are already created then.

I wrote a couple of tasks right there in deployer file to upload the resources. Something like:

/**
 * Upload ProcessWire assets folder
 */
task('upload_assets', function () {
	upload('site/assets', '{{deploy_path}}/shared/site/assets');
});

You actually only have to run it once via cli when in production, but could be handy while developing or on a semi-static site. In the latter case you can even include this task in the main deploy task.

P.S. I actually decided to include config.php and the wire folder to my version control as @Wanze once suggested. It makes it much easier to deploy (and a proper composer way probably will not come any time soon). So my configuration now is more defined comparing to  these vague thought described here - I put everything but the assets folder and the compiled static assets (I use gulp workflow, so only frontend sources are version controlled) in git. As I (for now) always deploy from the local machine. I compile frontend assets locally as a part of deployment process and upload them to the server in a task similar to one presented above. I even managed to make tasks for database upgrade. But it is not really useful as I can't simply upgrade db on production this way. I hope to master @LostKobrakai's Migrations one of these days and include them to the workflow.

  • Like 2
Link to comment
Share on other sites

interesting thanks for sharing :)

I commented the deploy:shared task out the first time so everything got created, than copied the shared stuff and re-deployed with the deploy:shared task enabled ;-) 

Link to comment
Share on other sites

  • 6 years later...

RockMigrations is your friend. We've been using it for years and thousands of deployments.

Here are the new docs: https://github.com/baumrock/RockMigrations/tree/main/docs/deployments

The resulting folder structure of a deployment will look like this (where the triple letters stand for a release hash from github):

current -> release-DDD   // symlink to latest release
release-AAA---           // old releases
release-BBB--
release-CCC-
release-DDD              // latest release
shared                   // shared folder
  • The current symlink will link to the latest release
  • Releases will be kept in the release-* folders (and you can configure how many to keep)
  • The shared folder will contain the persistent data shared across all releases (like site/assets/files and site/config-local.php).

WfvlHip.png

Does it look complicated? Maybe, but once everything is setup it's just "git push" and can't get any easier or more fun.

Does it take longer than moving files manually to the server? Maybe. But only for the initial setup. I've saved many many hours and it's always great to just "git push" and have everything magically appear on the remote server.

You want/need to have different staging/production environments to test out things or show some drafts to your client? No problem at all! Just push either to the "dev" branch or to the "main" branch and it will deploy either to staging or to production (depending on how you set it up and how you want it to work).

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...