Prevent the developer from executing code due to the creation of a weekly build

Question

Our development team (about 40 developers) has an official build every two weeks. We have a process that on the "build day" every developer prohibits passing code to SVN. I do not think this is a good idea because:

• Building will take several days (even weeks at a bad time) to do BVT.
• People cannot execute the code as they will, they will not work.
• People will capture all the codes in a huge package, so the general text is hard to write down.

I want to know if your team has the same policy, and if not how you do it.

thanks

Answer 1

• Select a revision.
• Check out the code from this version.
• Build.
• ???
• Profit

Answer 2

Usually the assembly is made from the tagged code.
If the label is defined (and does not move), each developer can fix as much as he wants: the assembly will continue with a fixed and defined set of code.

If it is necessary to correct errors on this set of generated code, the branch can then be identified from this label, minor corrections can be made to achieve the correct assembly before merging with the current development branch.

"Development efforts" (for example, assembly with its settings) should never block another effort (daily commit).

Answer 3

Step 1: svn copy / trunk / your / project / go / here / temp / build

Step 2. Massage your sources in / temp / build

Step 3: Build / temp / build. If you encounter errors, fix them in / temp / build and create again

Step 4: If successful, svn move / temp / build / builds / product / buildnumber

Thus, developers can check every time they want, and are not violated by the daily / weekly / monthly / annual assembly

Answer 4

Sounds disappointing. Is there a reason you guys don't perform Continuous Integration ?

If this sounds too extreme for you, then definitely take some time to learn how branching works in SVN. I think you could convince the team to either develop on branches, or merge into the trunk, or fix a “formal assembly” for a specific tag / branch.

Answer 5

I worked on projects with a similar policy. The reason we need such a policy is because we did not use branches. If developers are allowed to create a branch, then they can do everything they need on this branch, and not interrupt anyone else - the policy becomes "do not merge with the main one" during the weekly build period.

Another approach is to split the weekly build into a branch so that no matter what is checked (and possibly merged), the weekly build will not be affected.

Using tags, as VonC suggests, is also a good approach. However, you need to think about what happens when a tagged file needs a patch for nightly assembly — what if the developer checked the changes to this file because it was tagged, and that the developer’s changes should not be included in the weekly build? In this case, you need a branch. But label forking can also be a good approach.

I also worked on projects that make branches just as crazy, and it becomes a mess, trying to figure out what is going on with a particular file. Changes can be tied to several branches in the same timeframe. In the end, merger conflicts must be resolved. This can be a big headache. Despite this, I prefer to use branches.

Answer 6

We create a branch for each ticket or new function, even if the ticket is small (for example, it takes only 2 hours to fix it).

At the end of each coding part of each iteration, we decide which tickets to include in the next version. Then we combine these tickets in the trunk and release the software.

In this process, there are other steps in which testing is performed by another developer in each ticket branch before the ticket is merged with the trunk.

Developers can always code by creating their own branch from the trunk at any time. Please note that we are a small team with 12 developers.

Answer 7

Both Kevin and VonC well indicated that the assembly should be made from a specific revision of the code and should not block developers from new code. If this is somehow a problem, you should consider using other version control software that uses centralized and local repositories. For example, mercurial has a central repository, as in svn, but developers also have a local repository. This means that when a developer commits, he only commits his local repository, and the changes will not be noticed by other developers. After he is ready to transfer the code to other developers, the developer simply transfers the changes from his local repository to the centralized repository.

The advantage of this approach is that developers can make small code fragments even if it breaks the assembly, because the changes apply only to the local repository. Once the changes are stable enough, they can be redirected to a centralized repository. Thus, a developer may be able to control the source code even if a centralized repository is not available.

Oh, and you will look at the branches in a completely new way.

If you are interested in mercurial, check out this site: http://hginit.com

Answer 8

Wow, this is a terrible way to develop.

Last time, when I worked in a really large team, we had about 100 developers in 3 time zones: USA, UK, India, so we could effectively develop 24 hours.

Each developer will check the assembly tree and work on what they were supposed to work on. At the same time, continuous assemblies will occur. The assembly will make a copy of the presented code and build it. Any failures are returned to the last applicants (s) for the code for this assembly.

Result:

• Many assemblies, most of which are compiled in order. Then these assemblies began automatic smoke testing scripts to find any unexpected errors that were not detected during the sentence testing.
• Build failure detected early, early.
• Errors discovered earlier are fixed earlier.
• Developers only wait for the minimum time to send (they need to wait until some other developer who sends completes the send - this requirement is so that the build servers have a point at which they can capture the source tree for a new build).

Most developers had two machines, so they could work on the second error when running their tests on another machine (the tests were very graphic and caused all kinds of focus problems, so you really need another machine to do different work).

High-performance continuous development without dead time, as in your scenario.

To be fair, I don’t think I can work in the place you are talking about. It will be the destruction of the soul in order to work in this way unproductive.

Answer 9

I strongly believe that your organization will benefit from Continuous Integrations, where you will build very often, perhaps for every check of your code base.

Answer 10

I don’t know if I will shoot for this, but you really have to go to a decentralized solution like GIT. SVN is terrible about this, and the fact that you can’t complete it basically doesn’t allow people to work normally. For 40 people, it’s worth it because everyone can continue to work on their things and just push what they want. The build server can do what it wants and build without affecting everyone.

Another example of why Linus was right in saying that in almost all cases, a decentralized solution like git works best in real games.