Geek Answers Handbook

The idea of ​​continuous integration

In the software development environment where I work, we have a group of developers working in the same (Java) code base (currently using SVN). I notice that people often want to capture what they created without "breaking the assembly." Therefore, for this reason, I consider tools such as Git and Mercurial, which greatly facilitate branching and especially merging.

One of the things that I see is that if a developer commits “bad code,” then the code is violated for everyone. As an idea to avoid this, I would like to have a repository of an intermediate single function, which is simply the current "master", ONLY one set of changes for this single new function. Such a repository “intermediate single function” can then be automatically tested (code quality, unit testing, manual code verification, etc.) before becoming part of the main code base.

So, the workflow that I mean looks something like this :.

  • The developer creates a new function and performs it locally daily.
  • After a while, the developer quits and sends the whole set of changes for integration into the "main" repository.
  • The continuous integration system accepts the current “wizard”, applies a set of changes and checks the code (merge conflicts, PMD, Findbugs, ...), runs unit tests, checks the coding style, etc.
  • If the CI system resolves the "bad code", the developer is notified of the reasons, and the developer must resolve the indicated problems. In this case, the main repository does not change.
  • If the CI system resolves “well enough,” then the code will reach the “lead developer” or “code reviewer,” who checks the chosen solution and approves or rejects it.
  • An approved set of changes is then included in the main repository and is available for all developers to reinstall / merge.

I have some questions about this kind of workflow:

  • What do you do, it will work well in practice (i.e. is this a good idea or really messed up)?
  • Have any of you worked with anything like this before? What were pro and con?
  • Is there a "ready to run" script / procedure / tool / ... that allows you to run such a workflow (or a variant of this idea) in a minimal amount of time?

Thanks.

Background Note:

I worked as a developer about 13 years ago in a company where they built a similar workflow inside, and they had two nightly builds:

  • Version 'production': main code base
  • "Older version: The main code base with all new versions of all modified files.

Since this was the entire SCCS (lock-edit-unlock) model, there was no way to “lock often”; you had deadlocks for changing the code and all other kinds of unpleasant effects. What I'm looking for is basically good things about what I used then, using much better tools today.

+4
source share
2 answers

TeamCity has the function of fixing preliminary testing.

http://www.jetbrains.com/teamcity/delayed_commit.html

+2
source

In the company in which I now work, we thought about using this approach. In the end, we decided to use something simpler. We allow automatic assemblies to set a shortcut after a successful build, and we have a tool that we use to synchronize with this shortcut. Therefore, when someone breaks the assembly, other people will still be able to get the working version from the repository. A tool that syncs also ensures that if you have just submitted something, your changes will not be replaced by versions owned by the tag. For us, this work is excellent, but it is not suitable for your situation.

Hello,

Sebastiaan

+2
source

More articles:


All Articles