Good day. There is another question about the implementation of the GIT scheme.

In our work we use two servers.

  1. Develop (we want to test and show intermediate results on it)
  2. Production (we post only ready-made modules on it)

We have 8 developers, each working with its local copy of the project. During the day, developers must upload intermediate results to the develop server, after confirming the module’s work (a specific developer), it is necessary to merge the changes onto the production combat server.

How do you advise to implement the scheme of work with GIT? (how many branches? how to deploy to production, etc)

Thank.

Thanks for your reply. The scheme of our work. 1. The developer rules the module. 2. The developer makes a commit to Develop (here the question arises - what branches to create, considering that we have 8 developers; in most cases, each developer works with his module, should each create his own branch or commit to the wizard?) 3. The user checks / tests the operation of the module and if everything works, then this module must be put on the production server. How to implement this scheme? We didn’t use git before, so we don’t quite understand all aspects of working with git. We would be grateful if you describe the git scheme in our particular case. (we read similar articles but more questions arise) Thank you.

There is still a difficulty in understanding the following: Each developer commit to the master branch in order to allow users to see the result (develop domain suppose) Vasya and Peter put the work of their module into the master branch, Vasya's module is ready and Petit's module needs to be improved, as in this case produce a merge of a branch master with production (after all, Petit’s module is not yet ready)

  • det-random.livejournal.com/10262.html - vp_arth
  • For some reason, I have a feeling of deja vu, as if I have already seen this question ... - Nick Volynkin ♦
  • About releases: How to send a release to git? - Nick Volynkin ♦
  • About branching models: Proper naming of branches - Nick Volynkin ♦
  • В течение дня разработчики должны выкладывать промежуточные результаты на develop сервер - and if the feature is not completed at the end of the day, still upload it? - Nick Volynkin ♦

1 answer 1

By what you describe, it seems that you want to release as often as possible and test all changes before sending to the battle. These are the right goals.

During the day, developers should post intermediate results on develop server

Usually changes are not merged into a common branch until the feature is completed. Every extra merge is a loss of time and effort. And if you have to roll back the changes, it will be quite difficult.

Branches, tasks, releases

You can try this scheme:

  1. Developers make a new branch from master for each new feature. Every day they make commits to this thread. When the feature is ready, the branch is merged back into the master and a new branch is started for the new feature. I highly recommend merging with the creation of a merge commit ( git merge --no-ff ). Learn more about how to branch and merge: Proper naming of branches

    Before Merzh, it is desirable to perform such tasks:

    1. Review of the code, it makes the timlid.
    2. Testing, it is carried out by the tester. If it is not possible to automatically deploy to the server, then let him take the necessary git fetch; git checkout 123-branchname branch for himself git fetch; git checkout 123-branchname git fetch; git checkout 123-branchname and raises the site locally. If the design, layout, usability, etc., have changed, they should also be tested.

    Testing and reviewing the code can be done simply through branches, or you can add pull requests. Why do I need a pull request if there is a push?

    enter image description here

  2. The code from the master branch is deployed to the staging server automatically, every time a commit is made to master . Automation - through git hooks or a continuous integration server, depending on your capabilities and resources.

    On this server:

    1. The tester looks at the integration of changes from different developers.
    2. The manager or whoever is responsible for the product looks at the readiness of the features.

  3. When another commit to master is considered fit for deployment to a fight, the person responsible for the release makes a merge to the production branch. From this branch, the production server is automatically updated by the same mechanism.

    enter image description here

How to deploy

If you can, separate the git server and the server with the site. Depla through git pull does not scale well, it is better to configure via rsync , then you can easily use additional test servers. Setting Up and Deploying a Project Using Git

  • I recently tried Deployer.org for PHP projects. Quite well, you can define an infinite number of deployment goals. - ilyaplot
  • @ilyaplot is interesting, thanks, take a look. - Nick Volynkin ♦
  • There are more powerful deployment systems, such as Capistrano or Mina, but they seemed redundant and too sharpened for certain technologies and frameworks. - ilyaplot
  • @Nick Volynkin Please see the changes I made to my question. - Stanislav
  • @Stanislav I will see tomorrow, I have long left the workplace. ) - Nick Volynkin ♦