Level 65
So you want it to copy your files (from current dir to new) -> pull changes -> do any migration etc -> update symlink ?
Apr 10, 2015
4
Level 3
Envoyer Deployment question
Hi
I have noticed that whenever envoyer deploys it just re clones fresh piece of code from gihtub repo instead of just deploying code files that are changed like what deployhq does.
So I was wondering is that same behaviour applicable on envoyer. I don't want to keep running composer install again on each deploy.
Also is envoyer only tuned for Forge structure or Laravel what about Project repos having multiple laravel instances.
Level 8
I don't really see an issue unless your deploying every 2 minutes...the time it takes for my composer install to run on a slow day.
It would be more efficient for Envoyer to just upload the changed files after copying the latest release directory. Sure Taylor must have a solid reason for not doing that though
Level 7
Using this approach if something went wrong, you can easily go back to another release, without using git rebase and revert and what not.
Also, nope this is not only tuned for laravel and forge, you only have to link to a /current
Level 6
Is there an issue with running composer install each time? From my experience on Windows, Composer caches recently fetched packages, so if the version is the same.
The time should not be an issue for deployment. Everything is prepared by Envoyer in the background until it is ready, then the symlink is changed so that the new version becomes live instantly.
You could use systems that only transfer changes in code across, however Git is really good at managing code state, there's less change of an issue if you say "fetch branch master" or "fetch tag v1.2.3" - you know the code is whatever that branch/tag points to.
Your codebase would have to be fairly massive to justify only copying changed files across.
Please or to participate in this conversation.