Category: Admin & Best Practices
Apr 24, 2012
Migrating from one SCM system to another is never a trivial decision, so I’m always impressed by the steady stream of sites making the switch from Subversion to Perforce. The reasons vary, although the need for better performance and branching/merging usually top the list.
In any case, we always try to make the migration process as easy as possible. That means having a lot of migration expertise on our Support and Consulting teams. They can provide deep technical advice and, when a Perforce consultant is engaged, project planning and guidance.
We also develop some migration tools to make the mechanical aspects of migration – actually moving data from the legacy system to Perforce – as seamless as possible. We recently finished a major update for our Subversion migration tool. It is based on years of field experience helping customers move data into Perforce, and offers a lot of improvements over the older tool.
...
Apr 13, 2012
This is the last post in a three part series about managing dependencies with Maven.
In two previous articles I've described techniques for managing complex dependencies in software projects. I focused heavily on Maven, a software project management and comprehension tool. I emphasized Maven for two reasons. First, I've used it for years while developing plugins for Atlassian products. The Atlassian plugin SDK is built around Maven and provides a great example of managing a long set of build dependencies. Second, our own Java team at Perforce has had good success with Maven.
These articles spawned a few questions and discussions internally. I thought I'd share some of that, as I found it educational myself. I consider myself proficient but not expert with Maven, and I'm always surprised by how much it can do.
Can Maven be used for non-Java projects?
Yes. There are hundreds of archetypes for Maven, ranging from Java web application development to eBook publishing. There's also a well regarded extension...
Apr 11, 2012
This is the second post in a three part series about managing dependencies with Maven.
In a recent article, I described a few high level ways to manage a complex dependency tree in your projects. Now I'll go through a simple example using a Maven repository to help build and maintain a Java project.
Background
When Perforce rolled out the Remote Administration program, I helped to write part of the reporting tools. Part of the program is periodic reports on Perforce server performance. I designed the reports in BIRT, an open source report engine, and then wrote a Java program to invoke BIRT and generate the report automatically.
BIRT is a moderate complex product by itself, and so my Java program has to pull in the right set of BIRT libraries to compile and run. My program also needs log4j, a logging system.
Managing Dependencies in Ant
When I first built the project, I wrote an...
Mar 22, 2012
While I don’t normally find press releases very interesting, our friends at BigLever Software, a Perforce integration partner, created a very interesting way to picture the complexity of modern development projects. (BigLever’s CEO, Dr. Charles Krueger, also contributed a guest blog article on systems and software asset sharing.)
I’ve quoted the relevant bits below, but I think this graphic summarizes the complexity involved in developing systems and software that evolve over time (Multi-baseline), are customized for different product variations (Multi-product), and have a “Multi-phase” lifecycle. An example would be a software component for cellular communications. This component may be used in several chip sets, evolve as bugs are fixed, and of course go through a lifecycle where requirements and test cases drive changes.
The “Multi-baseline” axis is traditionally where Perforce, as a version management system, is able to offer solutions. ALM suites (whether best-of-breed or...
Feb 16, 2012
A good citizen of a secure world
The topic of security is a bit tricky for a version management system like Perforce. Although we need to keep security in mind, we're not a dedicated security system. Or, as one of my colleagues likes to say, Perforce isn't Fort Knox. It's the gold inside Fort Knox and needs to be protected. And, bear in mind that making data easy to find and use is a key requirement for Perforce.
Back in the good old days, most important IT systems were kept on closed networks guarded by big firewalls, so perhaps you could assume that security wasn't the concern of every application. Now, though, we know that those days are well and truly gone. Many companies have teams working on several continents, which may require less-than-ideal network connections. A lot of people want to work from home or while they're on the road. Personal mobile devices are all over the place. And the severity of malicious activity is worse than ever.
So keeping all that in mind, I'd say that Perforce tries to be a well-behaved part of a secure environment. A secure environment has a multi-layered, defense-in-depth design. It may include firewalls, policy restrictions, layered internal networks, and other pieces...
Feb 10, 2012
Over the last several years, Perforce has steadily improved its data replication technology. That’s good news if you have teams working in different parts of the world, or want to take advantage of development tools that put a lot of load on version control, like build automation. In other words, if you’re anywhere near modern software development, Perforce replication is good stuff.
The latest and greatest
Perforce replication started out with only metadata (the Perforce database), and expanded in the 2010.2 release to include full file content. A full replica was great for supporting automated read-only activities, like automatic builds, and of course also made read-only operations much faster for users at remote sites. Replicas also made for an easy disaster recovery (DR) option. The 2011.1 release smoothed some of the rough edges off of replica configuration and maintenance.
The 2012.1 release is baking as we speak, and will offer a pretty significant improvement to the way replicas are deployed and used. Replicas will now be assigned roles that define their purpose and the operations they support.
- ...
Jan 16, 2012
I often hear, and even throw the two things together in the same sentence myself, but they are two different things, and how you approach each one is important.
HA, in most users minds, means a machine that can immediately take over in case of a problem with the main machine with little down time, and no loss of data. Most often, they expect this to even be an automated process. For this task, I have always, and still do, recommend using clustering software and storing your metadata and versioned files on shared storage. The metadata should be on a fast/local SAN and the versioned files can be on either SAN or NAS for this setup. Since the data is on shared storage that can be moved between the two nodes of a cluster, no replication is required, and fail over and fail back can easily be handled by the clustering software.
DR, on the other hand, is something intended to take over in the event of a (surprise) disaster at the main site. Things like Recover Point Objective (...
