Posts Tagged automated build

Pattern for Private Prototype Development

by Dave Thomas

Your team has been coding a feature for a few days, across dozens of files, and everyone is excited with progress.  Deep into development, you find an interesting 3rd party library that may simplify your work and possibly take the team’s feature to the next level.  But it will require adding new files, moving some directories, and refactoring some critical code.  However, you’re not ready to commit your current changes because they are unfinished and will surely break everyone else.  Your changes need to be saved before prototyping in case of a rollback but also be integrated with prototype development.  And what if the new library is a bust?  If you start co-mingling the library integration with unfinished code, the potential revert process will be a complete nightmare and waste of time.

Private Versioning. With AccuRev’s private workspace, you can always commit your changes early, often, and safely without sharing amongst your peers.  But in this case you have two logical development efforts, the 2nd effort depends on the first and both need commits to preserve evolving changes.   How do you keep them cleanly separated and continue to work on both in parallel?

Stream Inheritance.  AccuRev streams have an intriguing and very powerful feature called inheritance.   Similar to how an OO subclass implicitly inherits methods from parent and grandparent classes, a child stream implicitly inherits versions of files & directories from parent and grandparent streams.   Taking advantage of inheritance, we can use streams to independently manage logical changes and cleanly maintain change dependencies without physically co-mingling files.

The Pattern.  Prototyping changes without co-mingling files can be done by simply creating a series of ‘personal’ or ‘private’ development streams (though, they are just regular dynamic streams). This pattern will create a “Feature”, “MyDevelopment”, and “MyPrototype” stream sub-hierarchy.  See Picture.

click to enlarge

click to enlarge

From your Integration stream (or equivalent), start by creating a “Feature” stream that will collect all changes from your entire team.  [See related blog, Stream-per-Task Pattern].  The majority of team members may have their workspaces directly from here.  Next, create a child stream called “MyDevelopment” that will track your personal ongoing development activity.  Finally, create a grandchild stream called “MyPrototype” to track changes that will be discarded or retained depending on the level of success.

The prototype development activity is committed, shareable, integrated, and yet cleanly segregated from both active feature and private development.

The “Feature” stream is the collection point of all in-progress development activities for the given feature from the entire team.  Developers will promote here frequently possibly kicking off an automated build with success/fail notification.   The “MyDevelopment” stream provides a collection point for all of your personal development changes.  This stream may be considered a “private” development stream simply because no other developers will likely use it – set a stream lock to be sure.  A lightweight Continuous Integration build (i.e. compilation only) may be performed on “MyDevelopment” for sanity sake or just compile and promote as a practice.  The “MyPrototype” stream is a collection point for all prototype changes. Even as new changes are promoted to “Feature” and “MyDevelopment”, the “MyPrototype” stream will automatically incorporate those changes (via inheritance) and the prototype developers will merge changes as necessary. The prototype development activity is committed, shareable, integrated, and yet cleanly segregated from both active feature and personal development. Also, by using a stream for prototype work, multiple developers can contribute and collaborate. If the prototyping work is deemed successful, the files can be promoted to “MyDevelopment”. If the prototyping efforts don’t work out – no problem – just remove the “MyPrototype” stream and re-purpose the workspaces.

The beauty of this pattern is that it isolates development activity by purpose without co-mingling physical file changes.   It lets the prototype developers go nuts and shoot from the hip while the regular feature developers (with the deadline!) work unimpeded and without fear of rampant changes — and everyone stays up-to-date.   And with no limit to stream depth, teams can perform prototyping efforts in parallel and/or perform prototyping based on existing prototypes by adding another child stream!  Furthermore, the pattern works for any size development activity or team, even for us Team-of-One developers with tons of ideas, fast fingers, and a few green screen x-terms (2 space, 80-char wrapping of course – <chuckle>).

This is a perfect example of how AccuRev empowers the developer to take control of their own development.  Creating streams is extremely easy and the stream browser provides unprecedented visibility into the entire development process.  With the right amount of security in place (Locks, ACLs, Triggers), the critical release streams (left side of the stream structure) can be locked down by the CM Admins, but the development related streams (right side) can be fair game for developers to create an environment that suits their purpose, such as prototyping.

Does anyone have a good story to tell about how this pattern (or equivalent) helped with a major refactoring effort or library upgrade?

/happy prototyping/ – dave

Posted in: AccuRev, Patterns

Leave a Comment (2) →

Continuous Integration…And the Ambient Orb

A lot of software development shops are turning to continuous integration strategies to verify integrations frequently and identify integration problems so that they can be quickly fixed. Continuous integration involves having an automated build system set up to run whenever new code is integrated. Automated unit tests are usually also run on each build to verify basic functionality. Martin Fowler wrote a great article (aptly entitled Continuous Integration) describing what continuous integration is and why it’s important. Many companies are now utilizing continuous integration servers such as CruiseControl, CruiseControl.NET, and Draco.NET to monitor their source code repository, usually managed by a software configuration management tool, and commence the build process when changes are committed. Of course, as Fowler points out, some people prefer the manual approach, and Jim Shore gives an excellent argument as to why Continuous Integration is an Attitude, Not a Tool (the title, and the article contents, are great!).

Whether a team chooses to utilize a continuous integration server or manually kick off their builds, reporting on the success or failure of the build and unit test suite is a crucial component to successfully adopting continuous integration. Specifically, it’s important for everyone in the group to be aware of the state of the mainline build. Many teams use wikis or other intranet web sites to report the status of each build. I have been to several companies that have large LCD panels hanging in the engineering department to display this information. A website is a great way to share information for groups that are geographically distributed. On the other end of the spectrum, in cases where all engineers are co-located, some teams have found more creative approaches to communicating build status. Fowler gave anecdotes of different colored lava lamps and even dancing rabbits being used as visual indicators of the build status. Although I found this amusing, I found it a bit hard to believe (we at AccuRev use a more subdued approach to report build status…email notification of the build status might seem a bit boring, but it works for us!). And, I found using a physical object to be limiting, especially as teams become more and more distributed. Well, in researching continuous integration, I ran across Mike Swanson’s blog posting about continuous integration and learned about the Ambient Orb manufactured by Ambient Devices. Now, this is cool stuff!!! The orb is a sphere of frosted glass that glows in a wide variety of colors and is also capable of visual effects such as pulsing and brightening and dimming. And here’s the best part…the orb has wireless pager electronics built-in. This means that the color of the orb can automatically be changed as the build status changes! And it means that, even if there are several distributed groups working on the same code, they can all use a funky object to see the build status. Apparently, there are similarly controlled lava lamps too, and other neat toys to make developers both productive and “retroactively” happy…

Posted in: Best Practices

Leave a Comment (0) →