Hi Ben -
At Carleton - it remains an open question how we are going to handle a
full git workflow. We currently update the code on our production web
server by doing an svn update (which pulls the latest code that we've
tested on a staging server). I use git svn to maintain a branch of our
production svn code in git, which I rebase and merge into the
reason_package master branch at github. We want to move to a full git
workflow but are trying to figure out the best approach.
Perhaps in July we should aim to have a session or workshop on Git. If
you guys have come up with something that works well, others could
certainly benefit from your experience. We may also be further along
with our git strategy at Carleton by then.
My current thinking is that we should do something like this:
1. Locally, create a git repo that contains everything
(reason_package, the web tree, etc).
2. Clone reason_package @ github and add it as a submodule in our uber
repo described in #1.
My understanding of git submodules is rather limited, but I think with
the above, somebody locally could clone the whole thing locally with
this:
git clone --recursive git://local/path/to/uber/repo.git
I think that in this world, you could have a deployment command on
your staging server that would ssh to the production server, and just
do a git pull to update a branch of the uber repo that represented the
production instance of the web site. You could presumably test using
that same branch on a staging server.
With submodules, you would have to treat work in reason_package itself
a little differently. Specifically, you'd have to commit changes in
the reason_package subfolder, and then go outside that folder to
commit the state of the submodule, but that doesn't seem so hard to
do. It also makes it very easy to pull changes from master or a
certain version and merge them into a reason_package_carleton branch
or something. All this said, I read about people having problems with
submodules and I remain too much of a git newbie to really know if
what I'm talking about makes sense. I hope to do some experimentation
soon to see how this all works.
Not sure this is helpful - would love to hear others thoughts on
managing core and local code with git, and deployment strategies.
Nate
On Apr 23, 2:41 pm, wilbbe01 <wilb...@wilburweb.com> wrote:
> Dear Reason Group,
> Steve and I met earlier today to try plan for our deployment and git
> strategies. We are curious as to what others are doing, as well as
> advice/criticism of any of our thoughts.
> We are thinking we will maintain our own fork ofhttps://github.com/carleton/reason_package.gitwith the master branch
> tracking carleton/reason_package's master. Our thought is that custom
> changes Luther makes that either are or are not bound to be part of
> Reason itself would reside in our repository in the master branch.
> Steve and I ended our discussions earlier with the idea of a branch
> for which our production/live code resides. This idea would provide us
> the ability to merge any future releases/updates/patches/etc as well
> as keep our production code separate from potential future
> enhancements which we have (or the rest of the community) added to
> master. We would potentially have other branches for development/test/
> etc as well.
> Does anyone have suggestions of how we may plan this better, or does
> this sound like a good method so far?
> The second half of my question is in deployment itself. There is a lot
> of discussion on the internet about git deployment strategies. For
> those familiar with platform as a service options, such as Heroku for
> python/ruby, you'll notice that deploying new code to a site is as
> simple as a git push to that remote. When pushed to Heroku, their
> servers are able to take the repository and put your latest code in
> production/test/etc.
> With SVN at Luther we have largely logged in to the production box and
> updated (I almost said pulled) changes manually from the production
> box's shell. Are any of the rest of you out there deploying in a way
> that the extra steps of deployment have been streamlined so as to make
> deployment to your development/test/staging/production/etc more of a 1
> step process so as to avoid the need for manual human changes? I know
> the git group repository idea with us manually pulling from the
> production/dev boxes would theoretically work, but it feels failure
> prone and I am just curious what others may be doing for deployment.
> Thank you.
> --
> Ben
