Single Release Point
Single Release PointRelease is when you deliver the system to the customer. Integration is when you merge your changes in the source repository (as CVS for example).
SingleReleasePoint would be a machine that releases the software from the source repository, possibly writing a mark in it, as for a example a unique build number. The result would be a working copy of the system that you can install on a production system.
SingleIntegrationPoint is when you can't integrate (check-in) your code from your development machine and you need to go to this machine (the SingleIntegrationPoint) and check-in. This is useful to serialize check-ins, but totally bogus when using CVS (ConcurrentVersionsSystem). Another simpler way to implement SingleIntegrationPoint is to have a token, like a doll, that is passed around whenever someone wants to check-in. It saves some time, but definitely it is slower an cumbersome when compared to the concurrent check-in feature of CVS.
FrequentReleases requires you to have a separate workstation to operate as your SingleReleasePoint. This physical token ensures that sequential integration takes place. Developers take turns using the SingleReleasePoint to integrate their code with the most recent changes and make a final run of the UnitTests. The image on the SingleReleasePoint is the last word in what the current system version is. It is critical for ContinuousIntegrationGemStoneStyle and is also just plain convenient.
A point I tried to make, and I think is still elusive, is that Integration and Release are not the same thing. Integration is what you do from your machine to apply your changes to the central repository (source code control). Release is what you do when you take the code out of the repository, not for modification, but for compilation, testing and even installation on production. People on this page use the two terms interchangably.
Actually the terms are even more confused, because some use the CVS terminology and others use the Envy terminology. Here is the translation table between CVS users and Envy users: (some Envy terms I forgot)
CVS Envy ---------------------------------- Checkout ? Update ? Checkin Version (integration) Tag Release Release ?-- GuillermoSchwarz.
It's possible to imagine other ways to do it, such as grabbing a reservation on a file or other techie solutions. Fact is, just going to the integration machine works so smoothly that there's no reason to go to anything more exotic. -- ?
What do you feel is the single most important thing the "piece of hardware" is providing you here? Is it that you have a separate CPU to run your own stuff, or is it that you have a separate physical location on disk that is storing your copies of the code you are editing/building (or something else)? -- ?
We mean machine, piece of hardware, computer. To me, a workspace is a window I can type things into and execute them.
This would be an example of KnowledgeInTheWorld? , especially if the release machine is located in a central location where others can see you walking over to the machine and tapping the keyboard. This provides a sensory cue that the work is done and ready to commit, as well as providing a much needed opportunity to get up and stretch.
The issue dealt with in SingleReleasePoint is the possibility of two programmers editing the same releasable chunk of code on their "machine", testing (perforce without the other programmer's changes), releasing, and the second smushing the first's change.
To resolve this problem we go to a separate releasing computer, load our code (detecting whether the code is not based on what is currently loaded on that machine), test, and release. By single-threading the load and detecting conflicts, we ensure that the second programmer will see that the programmer ahead of her edited the same chunk. She will resolve the conflict. -- ?
We (meaning the VcapsProject) have enough space near the SingleReleasePoint workstation (computer) for two people, PairProgramming, to work out a problem with integration. There is not enough space to get comfortable. You should have worked out most problems before approaching the SingleReleasePoint, the only problems remaining would be if someone just released something. In fact you passed them on the way to the machine. If a big problem does exist you should back out your changes, reload the latest version, and integrate at your own desk. (Hopefully you can grab one of the people who just released that code to help. -- DonWells
Benefits of having a single release point (possibly not physical):
A single release point is ideal for a single project. But what about when a common foundation of software is being employed on multiple projects with independent deadlines? Why wouldn't it work to distribute the UnitTests to more than one workstation, allow each project to verify what they need is working to meet their own release schedule, and delay the resolution of possible conflicts caused by independent evolutions until later?
Having worked this way for quite a while, I find it rare that collisions actually occur, and rare that the collisions can't be quickly resolved. But in those rare cases you need the time to do the debugging and refactoring right, which can make the SingleReleasePoint a choke-point for the multi-project software foundation. -- ScottJohnston
In a previous team, we used the style that you versioned off your changes (but didn't release them). We then ran a query that showed you all your unreleased changes in a little browser window (i.e. you got the real classes in the list). You then reloaded the entire system (e.g. overwrote your changes), and then using your list reloaded each of the classes you had changed (usually this was a small list - and in fact now I understand XP better it definitely would be a small list). You ran your tests and made sure everything worked (if it doesn't then you make your fixes, version up and reload the entire system again). If all was well, you changed ownership of each of the classes to be yourself (in retrospect - this was our token, however rather than having the single workstation token described above, class ownership acted as the token). you then compared your changes against what was previously released (to make sure you didn't lose any code - i.e. new methods you don't recognize). You then released each class. The idea was that if someone did the same thing with the same class in between when you became the owner and when you released, your release would fail (you weren't the owner anymore) and you could visit the new owner and work out what happened. In practice this rarely happened - it did the odd time and things were resolved, only in a few cases did it cause a problem where we had to resolve it on a single machine. I mention this strategy because it hints at how you can work in a more global sense. It does have some flaws however they are rare (certainly the SingleReleasePoint is safer if you can do it).
Now that I've read this page I can think of some improvements. I think I would try making the Java Package/ST Application ownership the token. You could reload as described above, grab ownership of the pkg/app, do your release and do any small integration needed if there are problems (because you have the token(s) for the pkg/apps involved). When complete, you then return ownership to some common user. If someone had changes to do and they noticed that the pkg/app ownership was assigned to someone else, then they either wait or they go and talk to that person. I think this is a bit safer as class ownership as a token is a bit fine grained. I would mention again that technique relies on good discipline and it is harder to achieve than the SingleReleasePoint, however if you are global it can work well (it also probably relies on VisualAge - although you could have a Wiki page with a list of pkg names and the token next to them) -- TimMackinnon
Thanks for posting this, Tim. It gives good insights and ideas about the use of "tokens"
We have one of those little round things that you shake, ask a question, and turn it over to see the answer ("Yes!" "Cannot foretell now ...", that sort of thing). That's our Token ... we also have a single integration computer (the Build Machine) but often the developers need to go back and forth between there and their workstations while integrating, so they take the Orb of Knowledge with them - unless you've got the Ball, you can't integrate. It ensures things are integrated only one at a time, and the sight of the Ball sitting there beside the Build Machine clearly states that the Build Machine is available (since sometimes it's occupied even though there isn't a person in the chair in front of it). - Anonymous
''We did something similar to this, but without the actual build machine. We called it the IntegrationBall. Whoever had it had control of the IntegrationSandbox?. If a pair ran into a flaw that required rework on integration, they kept the IntegrationBall on the driver's monitor. We used a big, pink, fuzzy die. The disadvantage of this method is that it is easy to forget to look for the IntegrationBall before starting. This was enforced by people throwing things when their work got stomped on. Frequently, throwing the IntegrationBall, in fact.' -- JeffBay
I like the name OrbOfKnowledge?. Some call this a MagicEightBall?. http://8ball.federated.com/
I still believe that the SingleReleasePoint is just a way around a basic failure of our development tools to handle integration of team changes. In database terms, it's a serialization of transactions. Yuck! I'd be interested in hearing what your IdealIntegrationTool would look like.
It does indeed enforce serial integration. That is a basic requirement. How finely you wish to chop things up into separate pieces is the question at hand. At the ChryslerComprehensiveCompensation project and the VcapsProject we decided to integrate at the entire project level (one piece). This enabled us to use a single physical token (a computer). If you divide your project up (TimMackinnon's experience suggests integrating at the package level) then you need to have a larger number of tokens and if you go so far as to integrate at the class level you need an even larger set of tokens. The solution most often employed is to use virtual tokens (file locking, or ownership tags within the source code safe itself) instead of the simpler physical token method.
But the hard part about source code management from an XP prospective is being able to accurately and concisely answer the question "what suite of UnitTests (and which versions) must my code pass?" This is the critical quality. If your source code management method can always answer this question than you will be OK. -- DonWells
If you're using CVS, does this mean that you're only checking in code ("ci") from the SingleReleasePoint computer? Or do programming teams check in their work as they go along, and the integrating team uses CVS tags to identify the latest integrated release?
In CVS you don't use SingleIntegrationPoint, you checkin from whatever machine you are and you don't take care if another is touching the same files. CVS handles merges gracefully and when confilct arises, they are resolved manually by the second checker-in. Can Wiki do something like that? If two editors change different lines at the same time, both go in, but if they conflict, the first succeeds and the secon fails?
In CVS you certainly need to use a build machine and build after any check-in, but that's not included in CVS. I have a tool called BVT. Others use AntHill, and I've heard others use CruiseControl. CVS tags are used, but not by individual programmers but by the tools. Usually that requires that the build tools use a special user, which is not a real user. BVT generates a web page that tells you which is the latest good build.
I think some people have a wrong view. A single release point is a concept that can be mapped many different ways, maybe it means a computer, but more usually it would be something that can serialize the work. For example, cvs ci/co can serialize many people, without the need for a single computer. It works by using a single shared filesystem. -- MikeStump
I feel sorry for our folks in England that would have to fly to California every time they checked-in their code. But I guess using only one computer it's the simplest thing that could possibly work.
This is a StrawMan, because XP requires that the team be physically co-located. I wish it didn't - then I'd get loads of free trips to California!
It seems to me that this is very old (1999) text - the people at ThoughtWorks have been doing automated half-hourly builds for the last year (2002) using a tool of their own devising called CruiseControl, and are now working with a team in India, integrating every half hour with CruiseControl internationally. I don't know that any of the old C3 team or old XP pundits still recommend or require a SingleReleasePoint. -- AlistairCockburn
How do people set up their workspaces to handle the transition between the integration machine and the local machine? Does one copy the source-files manually, or are the physical drives mapped in some way? When using version-control systems the files are usually locked to one machine and in order to integrate I'd have to submit my changes locally, requiring integration on the local machine before I could even get the code to the integration machine. Or do people use one branch per local workstation, submitting to that branch and then merging the branches at the integration machine? The whole concept of moving around code between two environments without using the version control system seems messy. Or is it that everyone else work in a UNIX networked environment where your own workspace is always available on any machine? -- AndreasAxelsson
Maybe the ideal integration tool is GnuArch?
GnuArch is a fabulous tool, but may not be great for those whose primary development workstation is Windows. In that case I would recommend a look at Subversion http://subversion.tigris.org
It's OpenSource too, and also supports the concept of ChangeSets?.
For those of you with $$$ to spend, check out http://www.bitkeeper.com (LinusTorvalds? Is that you? ;-)
LarryMcVoy? is the guy behind BitKeeper. LinusTorvalds used to use it for the LinuxKernel, but later decided to write his own (GitVersionControl).
None of these are "integration" tools, just SCM flavors... -- TimBrown
EditText of this page
(last edited November 12, 2014)
or FindPage with title or text search