Can Posted July 20, 2016 Share Posted July 20, 2016 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 ;-) 8 Link to comment Share on other sites More sharing options...
Ivan Gretsky Posted July 20, 2016 Share Posted July 20, 2016 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. 6 Link to comment Share on other sites More sharing options...
Can Posted July 21, 2016 Author Share Posted July 21, 2016 Interesting thanks for sharing! Even shorter And now I get the use of setting shared dirs/files haha 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.. 1 Link to comment Share on other sites More sharing options...
Can Posted November 4, 2016 Author Share Posted November 4, 2016 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 3 Link to comment Share on other sites More sharing options...
arjen Posted November 4, 2016 Share Posted November 4, 2016 Are the Assets folder and config.php empty? Or do you need to store the actual folders and files there? Link to comment Share on other sites More sharing options...
Can Posted November 4, 2016 Author Share Posted November 4, 2016 @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 More sharing options...
arjen Posted November 4, 2016 Share Posted November 4, 2016 Thanks Can. I also don't have the config.php and assets folder version controlled. So you copy the config.php and contents of assets to your shared folder and then deploy? Link to comment Share on other sites More sharing options...
Can Posted November 4, 2016 Author Share Posted November 4, 2016 @arjen exactly, otherwise the deploy:shared task would throw errors 1 Link to comment Share on other sites More sharing options...
arjen Posted November 4, 2016 Share Posted November 4, 2016 You do it manually or got a small bash script to handle the copying? Link to comment Share on other sites More sharing options...
Can Posted November 4, 2016 Author Share Posted November 4, 2016 Had them already on this server so just cp -r someDir/assets deployer/shared/site/assets Link to comment Share on other sites More sharing options...
arjen Posted November 5, 2016 Share Posted November 5, 2016 Thanks mate. Appreciate it! Link to comment Share on other sites More sharing options...
Can Posted November 5, 2016 Author Share Posted November 5, 2016 you're welcome buddy Link to comment Share on other sites More sharing options...
Ivan Gretsky Posted November 6, 2016 Share Posted November 6, 2016 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. 2 Link to comment Share on other sites More sharing options...
Can Posted November 6, 2016 Author Share Posted November 6, 2016 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 More sharing options...
MateThemes Posted July 25, 2023 Share Posted July 25, 2023 Hello, i know this is an old forum topic. But may it is possible that you write a short tutorial how you setup a deploy process?! Thank you Link to comment Share on other sites More sharing options...
bernhard Posted July 25, 2023 Share Posted July 25, 2023 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). 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 More sharing options...
Recommended Posts