Archive for September, 2007

Securing code with Cross-links in AccuRev SCM

September 28th, 2007

While working with an AccuRev customer the other day, we came up with a very interesting use for AccuRev cross-link capability that I thought would be  interesting to share.

This customer was looking for a way to centrally store their database DDL (Data Definition Language) files that are used to update the various DB staging environments that they use for development, testing, and production.  These DDL files are centrally developed by the DBA team, a common practice in most organizations, and can only be changed by that team.

Although these files are managed separately from the applications that use the databases, they need to be tracked alongside the application code bases to provide a complete configuration of the code and the database at all times.

At first, we talked about using change palettes to propagate the DB DDL files to the application streams and use triggers to secure the DB DDL directories so they couldn’t be edited.  Sounded like a lot of hard coding and script work.

CROSS-LINKS TO THE RESCUE!

This was a no-brainer for cross-links.  We setup a stream with ACL’s, just for the DBA group to modify and version the DB DDL files.  From this stream, they would create independent releases of the database.

Of course, the different applications are using different versions of the database at any one time, as well as customer specific versions of the database.

Using cross-links from the DB DDL streams and snapshots, the DBA team can independently and securely make changes to the database and cross link any version to any application stream.  The application stream will always retain the history of the database versions that have been linked in, while preventing developers from changing the DB DDL files.

What a huge time saver.  We didn’t have to custom script any security and will not have to manually promote these changes as they occur.  The Cross-link will automatically update the streams whenever the database changes.

How are you using Crosslinks?
 

No comments »

Posted in Best Practices

Tags:

Continuous Integration…And the Ambient Orb

September 27th, 2007

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…

No comments »

Posted in Best Practices

Tags:

The "Glass Half Full" approach to writing trigger logic for AccuRev

September 26th, 2007

Those making use of triggers in AccuRev software configuration management (SCM) have probably found that it’s possible to get as granular as desired when deciding what operations to restrict/allow and for whom. The support of regular expressions to define business logic can be quite a powerful mechanism while still being as flexible as necessary.

Here’s a twist to the standard sample logic written in the examples provided by AccuRev. As you can see, the sample uses the logic (and pardon the pseudo-code) “IF condition NOT met THEN disallow action OTHERWISE allow action”.

trigger_orig.jpg

This works for some situations and you can certainly add more scenarios where the action shouldn’t be allowed. But what may likely occur is that as your business grows or changes, you might find yourself inserting more and more “Hey, you can’t do this” rules. That’s where the twist comes in. This sample reverses the logic to “IF condition IS met THEN allow action OTHERWISE disallow action”.

trigger_fixed.jpg

As you can see, you have certain conditions that are going to sail through with the thumbs-up; if you get the thumbs-up, the trigger exits knowing you have the correct permissions regardless of what other factors may be involved, if not it keeps checking for a subsequent condition. If none are met, it will exit with the big ‘ol rejection. Contrast this with the first example, the “Glass Half Empty” way, where the trigger exits on the first failure and it doesn’t know that perhaps another condition was about to be met. The new way makes it a lot easier to maintain, order of the clauses becomes far less important, and I’d call it the “Glass Half Full” approach…

For extra credit, based on what was just discussed, can anyone point out the (perhaps) obvious optimization to the Glass Half Full snippet?

No comments »

Posted in Best Practices

Tags:

Reparenting Workspaces – What's the hype?

September 21st, 2007

By now you’ve probably heard about workspace reparenting in AccuRev. You know… the fancy drag-n-drop of a workspace from one stream to another. But what’s all the hype? Ultimately, workspace reparenting means that a workspace, on disk, can ‘morph’ into the configuration of it’s parent stream (See video) . So one day you are working on a mainline feature and the next day, with a single command, you can instantly have the configuration from a buggy release 2 months ago on disk, in the same location, with the exact configuration of files at that point in time. Poof! Reparenting VideoWell… first off, reparenting isn’t magic. You see, each and every stream in AccuRev knows at least two things – (1) its parent stream and (2) any active changes to its own relative configuration. Knowledge of the parent stream is by way of reference, in the same way that an OO subclass knows of its parent class. So if you change the parent reference, you instantly have visibility into the new parent configuration, in combination with any active changes that come along for the ride (as needed, most likely). Remember, workspaces are streams too!

Fun Toy or Power Tool?

The only “fun toy” you’ll find in AccuRev is the easter egg hidden in Help–>About where if you press CapsLock-Pause with your left hand you can play a tetris clone… ok, kidding. Workspace reparenting is a wickedly powerful feature that, when used properly, can save time, energy, and disk space and be a great powertool. So when is reparenting useful?

Retargeting a Delivery – Remember the time when you spent Saturday night cranking out a hot-fix… only for it to be reclassified to a lower priority on Monday and scheduled for next weeks build? No problem! Simply reparent your workspace from the release hotfix stream to the mainline area and promote the changes. done. go home.

Large Code Footprints – Lets say you have a 400Gb footprint of source code for any given release. On a particular day, you just finished committing 174 source files to mainline for a new feature. You then get tasked to the bug squad to tackle 9 high-priority bugs found in the recent production release. Rather than creating a brand new workspace from the old release snapshot, you can simply reparent your ‘mainline’ workspace and run update. You’ll most likely get the old versions of 174 files and probably a few dozen or hundred other files that changed… but the point is, you just get the delta. And waiting for 2G of changes over the wire compared to 400G is a significant time savings for you and others sharing the pipe.

Tracing Defects - You know those bugs that crop up and someone asks, “how long has that runtime defect been around?” Take a single workspace, create a unit test that forces the failure, then reparent to each and every release snapshot in question. Each time you do an update, you’ll get a corresponding configuration of code on disk -and- the tweaked unit test (active changes come along for the ride, remember!). Run the test, verify the failure. Bingo – a recipe to quickly test how far back a defect went. Just keep reparenting and running the test(s) until you find a configuration that works.

Rapid Application Development – Are you responsible for cranking out a few features all at once? Need to hop between them frequently? Sure, you could create a separate workspace for each feature and that’s probably a better practice in most cases… but nothing stops you from using a single workspace and context-switching by reparenting. As long as you keep/promote each feature’s set of files out of the workspace, then reparenting is a breeze. This works well if you follow a stream-per-feature paradigm.

So now you might say, “But isn’t reparenting the same as updating my local work area with a different ‘branch’?” Nope. Don’t forget about the most significant architectural difference between streams and branches… inheritance. We’ll save that for another thread.

One of the great things about workspaces is that they are a super tiny meta-data record in the AccuRev meta-database… just a pointer to parent stream and pointer to host machine and dir on disk. That’s it. Workspaces are cheap entities. Reparenting simply changes the single parent reference reference and updating only retrieves the deltas. Make reparenting part of your routine and the benefits will follow.

/happy reparenting/ – dave

6 comments »

Posted in Agile, Best Practices

Tags:

Stream Refactoring with Pass-throughs

September 20th, 2007

One of the greatest stories ever told is your software configuration management or CM process through the lense of a StreamBrowser. No other tool gives you the power to both visualize and manipulate your software development process in real-time. Over time, you’ll notice your stream hierarchy evolving into an elaborate tree effectively telling the story.

There are a number of techniques to help navigate the tree such as the GUI zoom feature and good naming conventions. But the unsung hero of stream organization is the pass-through stream. You probably already know about other types of streams such as dynamic, workspace, snapshot, and timebasis. Just like its siblings, the pass-through stream is also a configuration of source code but comes with a unique feature — all elements promoted to it are are automatically promoted to the pass-through’s parent stream, hence the name.

So what exactly are the benefits?

  • Group logically related child streams for organizational purposes.
  • A handle to reparent groups of streams without requiring an unnecessary promotion (to it).
  • Set include/exclude rules to be applied to all children streams without the unecessary promote step.
  • As an advanced technique, you can create a reftree on a pass-through to do software builds wherever the passthrough is currently parented — say last weeks build or last nights build — offering easy, visual, manual control over which configuration is built.

Lets put this knowledge to use. In the following diagram, you’ll see how a relatively sophisticated process model is cleanly organized Refactoring Streams with Pass-throughswith pass-through streams. There are a few pattern motifs used for organizing active development, nightly builds, system test builds, official release codelines, and customer one-offs. Notice how collapsing them all (left image) leaves the high-level process-centric streams nice and clean looking. Furthermore, notice how the names of the pass-through streams help tell the story of what activity is happening where.

Using pass-through streams is a passive refactoring technique that does not interfere with inheritance and can be introduced safely without disrupting development activity. In my experience, the more organized your stream structure, the happier the end users.

/happy refactoring/ – dave

No comments »

Posted in Best Practices, Patterns

Tags:

Developer Recipes: AccuRev + Eclipse + Ruby

September 18th, 2007

Related Recipes: AccuRev + JIRA + Eclipse (using Mylyn)

Love Ruby? Use Eclipse? Got AccuRev? Here’s a recipe guaranteed to get the mixture setup… stirred, not shaken.

Install Applications

  1. Install AccuRev 4.5. download. Follow the executable wizard.
  2. Install Eclipse 3.2. download. Follow the executable wizard.
  3. Install Ruby 1.8. download. Follow these instructions.

Install AccuRev Plugin in Eclipse

  1. Help –> Software Updates –> Find/Install
  2. Select ‘Seach for new features to install’
  3. Create ‘New Remote Site’ named AccuRev with URL http://www.accurev.com/download/eclipseupdate
  4. Checkbox ‘AccuRev’ and select Finish

Install Ruby Plugin in Eclipse

  1. Help –> Software Updates –> Find/Install
  2. Select ‘Search for new features to install’
  3. Create ‘New Remote Site’ named Ruby with URL http://updatesite.rubypeople.org/release
  4. Checkbox ‘Ruby’ and select Finish

Lets Rock! Now that the software is installed, lets put it to work. Here are three use-cases depending on how you need to work on your project.

Use Case: New Eclipse project / New AccuRev workspace. Starting from scratch? Have ruby code already in a depot? Do you know which stream configuration you want to work from? Then this is for you…

  • File –> New –> Project –> AccuRev –> Checkout from AccuRev
  • Choose “Create new AccuRev workspace and Eclipse project”
  • Follow the wizard to specify depot/stream/project/workspace names and directory location. Select ’simple project’ when prompted for project type.
  • Select project in navigator. Project –> Add Ruby Nature. This will declare the project as a ruby project.

Use Case: New Eclipse Project / Existing AccuRev workspace. Already have an AccuRev workspace with your ruby code? Just need to setup a new eclipse project? Then this is for you…

  • File –> New –> Project –> AccuRev –> Checkout from AccuRev
  • Choose “Create new Eclipse project in existing AccuRev workspace”
  • Follow the wizard to select the workspace and name the project. Select ’simple project’ when prompted for project type.
  • Optionally, the project may need to be declared a ‘ruby project’. This may already have been done. Either way, select project in navigator. Project –> Add Ruby Nature.

Use Case: Existing Eclipse Project / Existing AccuRev workspace. Already have an eclipse ruby project? Is your project already on disk in an AccuRev workspace? Then this is for you…

  • File –> Import –> General –> Existing Projects into Workspace
  • Select AccuRev workspace directory containing the Eclipse .project file
  • Checkbox the projects found then “Finish”
  • Setup AccuRev for the project with: RClick Project –> Team –> Share –> AccuRev

Test either Use Case by creating a new Ruby Class. If you don’t get any errors, so far so good. Otherwise, if the ruby nature is not set, the new class wizard will warn you when you enter the class name. Now verify the new class shows up in Team –> AccuRev Searches –> External search view. This verifies that AccuRev is connected.

I hope this batch of recipes helps you get up and running flawlessly with AccuRev + Eclipse + Ruby in no time!

For those new to Ruby+Eclipse, our friends at IBM have a great tutorial. Also, the folks at O’Reilly have a great article about using Rails+Eclipse.

/happy coding/ – dave

1 comment »

Posted in Agile, Best Practices

Tags: