Archive for September, 2007

« Older Entries

Securing code with Cross-links in AccuRev SCM

September 28th, 2007 by rmohr
Share|

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 by jtalbott
Share|

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 by jtalbott
Share|

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 The "Glass Half Full" approach to writing trigger logic for AccuRev

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 The "Glass Half Full" approach to writing trigger logic for AccuRev

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: