And here I was thinking that this was obvious and most people used something like Capistrano... It's shocking to me the amount of people not using some sort of SCM-based deployment method. =P
Let's deploy via Git
71–80 of 113 posts
Re: Let's deploy via Git
#72git is a SCM and should not be on production systems.
instead you should have a build server which builds up a package (rpm, deb, tarball?) which is then used to deploy across the production environments.
you should also not compile JS/CSS etc on production system that is what the build server is for.
anything installed on a production system should be 'required' for the app to actually run.
-
that said, you can use capistrano (and other tools like this) to update 'demo' environments and dev environments (with git) however the actual TEST and STAGING environments should mirror the PROD environment (packaging).
Re: Let's deploy via Git
#73Shouldn't it be:
git --bare init
Re: Let's deploy via Git
#74This is a pretty neat hack, but not really good for a true production deployment system. Rsync is a far superior alternative. That being said, git should definitely be incorporated into the workflow such that, for example, you have a "live" branch which always reflects what is to be on production frontend nodes. From there you do 1) git pull origin live 2) rsync to live servers 3) build/configure/restart/etc. Set -e…
Anywhere that I have a say in the matter, FTP is disabled. I've been a fan of rsync for years and have a bunch of scripts that can make the whole process seamless. That said, I'm starting to be won over by git deploys. The reason I've started to like git is deletes. You can handle them with rsync: rsync --delete The problem is that some projects have content uploaded in the same file tree (simple CMS installs). This…
> Content can be mixed in the same tree and hidden with a .gitignore file
Note that rsync also allows fairly powerful in-tree tweaking of details: if you give it the "-F" option, it will look for ".rsync-filter" files (see man page for details).
Re: Let's deploy via Git
#75Shouldn't it be: git --bare init On the server?
No, because it needs to be checked out (that's the deployment). As a usual git server, yes --bare is the way to go. In this case you could alternatively use --bare in a ~/repos/example.com dir and set the $GIT_WORKING_DIR environment variable to ~/www/example.com for checkout.
Re: Let's deploy via Git
#76Earlier quoted context omitted.
And why is rsync superior?
Part of my reasoning is that rsync is specifically made for this kind of thing, whereas git is specifically made to synchronize coding among multiple developers. So my argument is partly theoretical and less practical. But for an argument based in pragmatism, rsync has tools such as the --delay-updates flag, which allows your entire deployment procedure to become a pass-or-fail atomic operation. This kind of assuranc…
The same thing in git:
git fetch && git reset --hard Re: Let's deploy via Git
#77Aaargh ! Build on a build server Scp to live server along with generated config Install with native package tool and hook into native service manager Use salt / puppet / chef to do everything after initial build on your target servers. Be nice.
Yes, exactly. Some of us still have compilers! Or more than one git repo.
Or have library dependencies that aren't all dumped into some vendor directory, but actually need a system-wide upgrade.
Re: Let's deploy via Git
#78git is a SCM and should not be on production systems. instead you should have a build server which builds up a package (rpm, deb, tarball?) which is then used to deploy across the production environments. you should also not compile JS/CSS etc on production system that is what the build server is for. anything installed on a production system should be 'required' for the app to actually run. - that said, you can use…
On one end, you have stone age developers who need Visual Studio on production systems because that's the only tool they know.
On the other end, you have hipster developers who need Git on production systems because that's the only tool they know.
Re: Let's deploy via Git
#79This is a pretty neat hack, but not really good for a true production deployment system. Rsync is a far superior alternative. That being said, git should definitely be incorporated into the workflow such that, for example, you have a "live" branch which always reflects what is to be on production frontend nodes. From there you do 1) git pull origin live 2) rsync to live servers 3) build/configure/restart/etc. Set -e…
Both Git and Rsync are incompetent deployment tools for many reasons I will not go into in a comment as there are quite a few articles expounding on the virtues of not using your VCS. There are also numerous reasons why rsync is inappropriate too (what if you push up a nasty bug and you have to revert? Op, better go revert to my tagged release then rsync again - this is ugly in comparison to versioned releases combined with proper use of the operating system's dominant package manager where you can upgrade/downgrade an application based on its version...)
I generally see four stages in the devops maturation of a programmer:
1. I rsync my code using pre-built commands in Fabric when I'm ready to push.
2. I write code and have hooks on the server to pull the repo when I tag a release in my VCS.
3. I use my language's package management system to build a source distribution that includes all of the necessary static assets, the web application, and any database migration code; I also use a sane versioning scheme to keep track of releases. When I want to push I use a build system that hooks into my continuous integration server and builds a distribution whenever the senior programmer tags a release. It is then made available to the production server in a deb or rpm repository where the senior programmer can then just run an update command (that updates with the new distribution and runs any necessary database migration or post-upgrade hook scripts).
4. You are so big that you've got a custom deployment system built on-top of BitTorrent (ala Facebook) or something similar.
It should be obvious where I'm at - I progressed from being an adherent to VCS deployment, to rsync only, to a proper source distribution release system. I haven't managed the devops for a team/application the size of Facebook yet but I'm sure I will get there soon.
Re: Let's deploy via Git
#80Earlier quoted context omitted.
Security. Are you 100% sure that there is nothing you are exposing via your git repo that you want to keep away from the person who manages to hack your server or discover some means to reach the repo externally? Getting hacked is not inevitable, but if you treat your systems as if it were you'll be a lot safer if it does ever occur.
If there's anything in your repo history that you don't want a hacker to find you can just remove it and force push.
"Just remove it" is hard, because:
* It may be hidden in some old commit (e.g: some password)
* You'd need to rewrite all history from that point
* Force push doesn't necessarily clean the data from the remote