Best way to run build scripts before deployment of web app?
When working with a git repository that holds all source assets and a
grunt build script or
composer install that needs to be ran before it will function, what is the best way to deploy it to the production server? Here are some solutions I came up with:
Keeping a local copy of the production stage (run the build script and composer install, then deploy to server through (s)ftp). This seems impractical and adds at least one extra step to the deployment process.
- composer.json specifies dependency, but no composer.lock was found
- How do I get Composer to download the latest commit in the master branch from GitHub for a package?
- Composer & composer.lock in GIT and merge conflicts
- Composer package not found in private repository
- github on server - Your local changes to the following files would be overwritten by merge:
- How to deploy with Composer and Git without downtime?
Creating a distribution branch, tracking the compiled / concatenated / minified files on there. This seems unintuitive and, like the first option, adds an extra step to the deployment process.
Using capistrano or a third-party deployment tool that will ssh into the production server, clone the repository, run the build scripts and create a symlink to the newly installed version. This seems like the “neatest” solution although it requires full access to the server and might have some security implications.
I keep running into this problem and thus far I have resorted to the first option (which is more of a manual workaround in my experience)
One Solution collect form web for “Best way to run build scripts before deployment of web app?”
One method I have seen working is to combine local build scripts with simple git-deployment and using two repositories: e.g. src and www.
Your src repository contains sources and build scripts, tests etc.
The build runs locally (composer, grunt, sass, js-min etc) and outputs the ‘static’ result across to the www / htdocs folder in the www repo.
The www repo is committed by the build and pushed to the deployment remote.
The deployment remote is on the production www server, with a post-receive hook which checks out the head (from a bare repo in /var/git/yourdomain) to the web server (e.g. in /var/www/yourdomain) which is a git working directory.
It’s basically simple, with little proprietary technology (beyond grunt, composer and git), but of course the details will take a while to get right.
I’ve found building to a branch is a nightmare, partly due to git’s tenacity on tracking files and having to avoid some merges. It makes it really hard to do build cleans for example. You’d have to at least have a separate www folder you’d build into an essentially duplicate any back-end scripts which weren’t compiled (like PHP). And versioning and branching dev v.s. releases is sometimes at odds. Having two repos separates this completely, and allows you to have deployment branches deployed to different websites for example (staging, prod).
Of course the git deployment method means you do need “full” access to the host to install git, the hooks and have ssh access. But most web hosts provide ssh access?
I’ve found git-deployment to be extremely reliable and trouble free.