Home / server / Questions / 599134
In Process
Abhishek Gupta
Asked: 2014-05-29 07:10:41 +0800 CST

Remote Debugging and deployment of a Project Built Locally

  • 772

We work on our projects locally, and deploy them on remote servers for testing. This is currently done via git commits/push/pulls. But the problem here is that most of the commit contain errors and/or break the code in significant manner due to the lack of testing.

Is there a way we can deploy the code on the remote server without using git commits, or some sort of temporary commits or patch or any other mechanism? And only commit, whenever it is important.

git

3 Answers

  1. You should always encourage commiting often, not discouraging it.

    You should have several branches in your git server, at least dev/staging/production to handle that situation. Google 'development workflow' and you'll find several examples.

    Finally you should look at CI servers, like jenkins

    • 1

  2. Make use of branches!

    E.g.

    Create a develop branch where you and your team usually works in, that can contain bugs, even unfinished code.

    Then create a release branch from the develop branch. Now you can commit code into that branch to get the software into a stable state so that testers can work with it. Of course it's not allowed to merge the develop branch into the release branch once again.

    As soon as your software in the release branch is stable and thoroughly tested, merge the release branch into the master branch and then back into the develop branch. After that, just delete the release branch.

    Following this workflow...

    • the master branch will only contain stable and tested code. Yay :)
    • the release branch won't suffer from breaks the devs introduce in the develop branch during the lifetime of the release branch
    • the develop branch will profit from stabilizing work that was done in the release branch. In fact, you should merge the release branch into the develop branch (not the other way!) as often as possible.
    • 1

  3. Abhishek this sounds like a human problem, not a git problem. Your coders need to test their work before committing. Shame is a pretty good tool here, used with humor. Loud shouts of "who broke the build?", emails, informal rules that the last one to break the build buys lunch... you figure out what works in your shop to get a habit of testing before committing.

    • 0