Code versioning between test/production server?

Alexander Korotaev2011-06-20 10:43:20

CVS

Alexander Korotaev, 2011-06-20 10:43:20

There is a large project, more than 1500 files. In accordance with the rules, development is carried out on a test server, and when certain features are accepted, the corrected files are migrated to the production server by copying. Both servers have svn, ci.
Faced the following problems:

Some comrades correct bugs on the combat server, tk. on the test one, features are already screwed on this code, and then they forget to make these changes on the test one. What turns out the next time these files are copied from test to production.
Features can be complex and affect a bunch of changes in various subprojects. It often happens that these subprojects do not merge, which also causes a lot of misunderstanding ...
Some features are tested for months, and in the end it turns out that the developers do not remember which files to submit for combat so that everything works as it should and nothing falls.

Therefore, I would like to ask habranarod, how did they solve this problem?

Answer the question

In order to leave comments, you need to log in

6 answer(s)

Shedal, 2011-06-20
@Shedal

It is not clear why developers have access to the svn of the production server. By the way, why does it need svn at all? Isn't it enough to have only the latest build of the application there?
And so, yes, if the air force has how many development branches, keep the main one in trunk, the rest in branches, do merge if necessary.

mark_ablov, 2011-06-20
@mark_ablov

git + brunches.

Denis, 2011-06-20
@uscr

Git.
There is a develop branch, there is master.
Each developer starts a separate branch for each new feature. Thus, you can cut an unlimited number of features at the same time, and they will not intersect.
Each developer has at least one virtual machine (xen server) for tests.
After finishing a feature, the branch of this feature is merged with develop.
There is a test server, to which the develop branch is merged for final tests.
If all is well on the test server, develop is merged into master.
So. In develop, there is always a conditionally working “fresh” one. In master, only tested code, ready for release.

Iskander Giniyatullin, 2011-06-20
@rednaxi

the trunk contains the production version + bug fixes, all features are made in branches, after successful testing on the dev server, the branch is merged with the trunk and uploaded to the production server.

Alexey Kulikov, 2011-06-20
@clops

Our model is as follows:
* Trunk is de facto not stable
* From Trunk once a month we branch off “release-year-month” and it goes into production in a month
* All bugs are fixed only in the production release
* All features are in the trunk
* Team lead time merge releases back to the trunk per day.
For example, we currently have two active branches: 1106 (now on the production server), 1107 (future release) and trunk (from there, the earliest features will be in production in August).

xSus, 2011-06-20
@xSus

We had the following practice:
1) several strums. the main is always the latest approved version. those. something that can be uploaded to the combat server.
2) the development of a new feature is in a separate branch, on which the main is merged daily. the code from the branch gets into the main after approval and testing.
3) before uploading to the combat server, a branch was created in which only fixes were made. after each fix, the branch was merged to main.
the main thing is not to confuse the direction of the merges.
If I find another article now, I'll attach the link.