Github and production server

Question

If one develops his code on local machine, and checks in his changes to github, then how does this go from there to production?

Say you have a production server running the very code you are working on. After I am done working with the code, and push to github, how can I automatically put that newest changeset on the production server? ( other than scp'ing). I guess I'm looking for what the conventional way to do this is.

Answer 1

You can achieve this by use of the appropriate git hooks. Just check documentation for more details of the various hooks.

The main idea of flow you ask for is as follows:

• You possibly have a local machine, and a local git repository on it.
• You get a remote git repository like ones on github.
• You get a production http server, that runs your application.
• You push from your local git repository to your remote git repository.
• You will use appropriate hooks, here post-receive will be necessary, on your remote git repository.
• This hook will make a request to a http url you have determined on your production server, like any other http application urls of your application, wirtten in language of choice of yours.
• This url on your production server will trigger the functions you have written that execute the commands like git pull origin <branch-name> to pull changes from your remote git repository, programming languages have functions to call command line executable tools like cd, git, grep etc.

In summary, you push to remote git repository from local git repository and git calls production http server to pull from remote git repository.

That's it. You do not have to configure/learn/buy any other external 3rd party services.

Answer 2

Say you have a production server running the very code you are working on. After I am done working with the code, and push to github, how can I automatically put that newest changeset on the production server? ( other than scp'ing). I guess I'm looking for what the conventional way to do this is.

The conventional way is to not do that. There's two bad processes here: 1) Automatic pushes to production and 2) Using version control as a release system.

DON'T get into a code & fix loop.

The desire to make pushing to production automatic from Github implies that you're doing it a lot. So often that you wish it would just happen. This indicates that you're in a code & fix loop, and that you're possibly even testing changes in production. This is a bad practice. Automatic pushes to production only enables it.

DO automate push to production.

Even if it's just a script that runs rsync or git pull, you want that script. Pushing to production should be a matter of running a script, not typing a bunch of commands. Why? Humans make mistakes.

DON'T automatically push a branch to production.

You still want a human in the loop to push the button.

First and foremost, did you acceptance test it? I don't mean just some developer poking at it on their development machine, or running unit tests, or even a CI server. I mean has someone representing your user played with your site to make sure it works and that the new feature is a desirable one? This could be an actual user, or it could be a surrogate like a Selenium script.

Second, automatic push to production means there is no safeguards. If a developer accidentally pushes a change it will immediately go to production. No safety net. No "oh crap" moment ten minutes later.

Third, what if the change involves more than code? What if you need to make a change to the database and there's scripts to run? You need a release manager, and we'll get to that.

Fourth, what if marketing wants a release date? What if your users want a more regular schedule of changes? Now all devs have to hold off on pushing which gets awkward.

DON'T use Git as a build or release system.

Git is a version control system. It does that very well. It is not a release or build system. While it can sync code very well, it cannot do all the other things that are required of a release or build system, like running migration scripts, or compiling code.

You need a release system. Can can shove Git into that role, but things will rapidly break down.

DO have a staging server.

That safeguard is a staging server. This is a server configured as closely to production as possible (hopefully built and managed in the same way as production) but detached from production. For example, it would have its own database.

This gives you a place for people to play with and verify your new release before actually releasing it.

Even then I'd say to not automatically push to staging. This makes it unpredictable to know what version you're testing. QA people hate having everything change out from under them without warning.

DO tag your releases.

Rather than automatically pushing a branch when it's updated, you can push when a new tag appears on your staging or production branch. This allows you to speak intelligently about what is on the staging and production servers ("it's v2.3.12"). Using semantic versioning can even provide information about how important this release is.

Even then I'd caution against making this fully automated. Have a script that automates releasing the latest production tag, but have a human decide to push it.

Answer 3

You can use git with branches. First setup your Developer branch

    #git checkout -b Developer

This developer branch will be the branch you are working on. On the server setup the production branch

    #git checkout -b Production

next push your code that you developed to the developer branch

    #git checkout Developer
    #git add -A
    #git commit
    #git push origin Developer

On your server merge the Developer branch to suite your needs

    #git checkout Production
    #git merge Developer

That's it.

Try looking into git documentation about branches. https://git-scm.com/documentation