Reason/php deployment and Git

[wilbbe01]

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 of
https://github.com/carleton/reason_package.git with 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

[Nate]

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