git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: H <agents@meddatainc.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Location limits on development, staging and production environments
Date: Wed, 31 Jan 2018 17:54:07 +0100	[thread overview]
Message-ID: <259af179-cdf1-1f27-95e4-b94f7ca12085@meddatainc.com> (raw)
In-Reply-To: <e737ea6f-493f-f6e4-7491-ee9c19609ee2@meddatainc.com>

On 01/30/2018 03:48 PM, H wrote:
> On 01/29/2018 10:02 PM, Bryan Turner wrote:
>> On Mon, Jan 29, 2018 at 11:08 AM, H <agents@meddatainc.com> wrote:
>>> I am a newcomer to git looking to set up a web development environment where individual computers are used for development, the development.git, staging.git and production.git repositories are stored on an external server reachable by password-less ssh and the staging and production websites are on yet another server, also reachable by password-less ssh from the git-server (and the development machines).
>>>
>>> Locating the three git repositories on an external server works fine but I have not been able to have the staging and production deployment files on another server. I believe this is what is referred by GIT_WORK_TREE and based on what I found on the web I created a post-receive hook of staging.git with the two lines:
>>>
>>> #!/bin/sh
>>> GIT_WORK_TREE=user@1.2.3.4:/var/www/html/dev.whatever git checkout -f master
>>>
>>> I believe this should deploy the files from the development work tree.
>>>
>>> The above, however, fails. Should it work? I am running git 1.7.1 on CentOS 6.
>> No, I wouldn't expect that to work. GIT_WORK_TREE is not remote-aware
>> in that way. It's expected to be a normal-ish filesystem path.
>>
>> Based on your description, and the hook you've written, it seems like
>> your intention is for the source to automatically be fetched and
>> checked out on the staging environment after each push. (This is
>> dangerous, and likely _not_ what you actually want, but I'll get to
>> that in a moment.)
>>
>> One option would be to setup something like NFS, so the git-server can
>> mount the filesystems from the staging and production nodes.
>>
>> A different, likely better, option would be to have the post-receive
>> script on the git-server use straight ssh to trigger a checkout script
>> on the staging server, e.g.:
>> #!/bin/sh
>> ssh example@staging-server -C /opt/deploy-staging.sh
>>
>> Your deploy-staging script would then do something like:
>> #!/bin/sh
>> GIT_WORK_TREE=/var/www/html/dev.whatever git pull origin
>>
>> That said, though, having such a simple script is dangerous because
>> Git is fully capable of having receiving multiple pushes concurrently,
>> and they can all succeed as long as they're updating different
>> branches. Since your script isn't considering what branches were
>> changed by the push, it could end up triggering simultaneous git
>> processes on the staging server all attempting to deploy concurrently.
>>
>> The stdin for the post-receive hook receives details about which refs
>> were changed, and you'll likely want to update your script to parse
>> stdin and only try to deploy staging if a specific, relevant branch
>> (master in your example) has changed.
>>
>> Lastly, I'll note that using post-receive will make the pushing
>> (remote) user wait while the staging server is deployed. If that
>> process is likely to take very long, you might want to decouple the
>> two somehow.
>>
>> Hope this helps!
> I should perhaps also have mentioned that although I am the only developer, I may use different computers to develop on. IOW, there should not be any conflict due to code being pushed by multiple developers.
>
> Let's see if I understand this correctly:
>
> - Unless NFS is used, the git archive and the deployment of the website code in this case should reside on the same computer.
>
> - The combination of the checkout script and the deploy-staging script should work provided not multiple updates to the same branch are pushed at the same time.
>
> I will try this later today but any other hints or suggestions you may have would be greatly appreciated!
>
I modified post-receive in the hook directory of the staging git archive on server 1 as per your first example and created the deploy-staging.sh script on server 2 where the staging website resides in /var/www/html/dev.whatever (as well as the live website in /var/www/html/whatever. However, when trying out the deploy-staging.sh script, it fails with the error message "...not a git repository...". I do have git on server 2 but what else would I need to set up to run this successfully? Note that the git repository is on server 1 and I am deploying to server 2.

Thanks!


      reply	other threads:[~2018-01-31 16:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-29 19:08 Location limits on development, staging and production environments H
2018-01-29 21:02 ` Bryan Turner
2018-01-30 14:48   ` H
2018-01-31 16:54     ` H [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=259af179-cdf1-1f27-95e4-b94f7ca12085@meddatainc.com \
    --to=agents@meddatainc.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).