3 ms·
What about simply putting a "deploy" script into your main source directory? Executing ./deploy is even less work than "git push" into a special remote re
by vog 12y ago
What about simply putting a "deploy" script into your main source directory? Executing
./deploy
is even less work than "git push" into a special remote repository/branch.
This "deploy" script would execute RSync and whatever needed to update the destination machine, without any server-side magic behind the scenes. It could also execute "git push" so you don't have to remember to push before deployment.
- klauserc 12y agoIMO the neat thing about a "git push" deployment is that you are deploying a particular commit. The build server could annotate the build with the commit's hash, making that deployment reproducible. If you just have a local ./deploy script, a dev might deploy changes that never make it into version control. (Even if ./deploy forces the working copy to be clean and the index to be empty, the dev could still "git reset --hard" afterwards and the version that has been deployed is lot)
- justizin 12y agoor howabout a Capfile and use capistrano? it's abused for many purposes, but its' job is managing versioned deployments which can be rolled back. you want this as early as possible, don't shun learning a tool for a couple hours for two years because you don't think you need its' power yet, start getting to know it so you're ready when you do.