Category: Performance
Mar 30, 2012
Continuous integration and Agile development are two distinct but related trends in software development. Continuous integration (CI) is really about increasing transparency, but usually manifests itself as automated build and test routines. To put it very briefly, building and testing early and often is a great way to make sure that you’re actually building what you wanted to, and expose potential problems early on.
Agile development has several foundational guidelines, and increased transparency is perceived as a key benefit of Agile development. In practice Agile teams like to test their work immediately after (or in some cases before or during) development, to make sure that the delivered product actually delivers value to the customer. That again has increased the need for rapid automated build and test cycles.
The natural culmination of these trends is often characterized with words like massive and extreme. One of our customers presented a talk at the last user conference on ...
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 13, 2012
"Use the right tool for the job." my father would say, as he hammered a screwdriver into a rusted set of brake drums.
Of course, if you don't have a chisel, you make do with what you have at hand. But when a tool better suited for the task at hand comes along, you are smart to start using it.
Git burst onto the SCM scene in exactly this role- packing not merely one better tool, but a whole bag. For those developers able and willing to master Git's arcane logic, fast and private branching, easy context switching, speed from running purely local operations on full local history, and a flexible and powerful command set became some of Git's sweetest come-hither features.
Need to stop work on a big feature to fix a critical bug in a release? No problem; switch over to a new branch, fix the bug, and switch right back to your longer-term work. Need to pull just some of your work out of one development branch and into another? Cherry-pick, use a patch, or rebase. For many developers, Git's features make it easy to perform these tasks. Git helps you do your job. Git makes you a better developer. It's an easy next step to conclude Git is the perfect SCM!
Not so fast! SCM is more than wrangling...
Oct 12, 2011
Distributed development can mean a lot of things depending on the context. I think of it as two related but distinct areas. I'd like to dive into those areas and talk a bit about how P4Sandbox will help both cases.
First, there's the idea of supporting a user base that is geographically distributed. Companies big and small are collaborating with partners or offices around the world. Just here at Perforce, we have offices in the US, Canada, the UK, and Australia. In this context, Perforce has a lot to offer, including proxies, brokers, replicas, and now P4Sandbox. Proxies, brokers, and replicas are tools deployed as part of a coherent architecture to offload file transfer work or read-only operations from the main server. They also help with general scalability, supporting large user bases or heavy automation. With these tools, more data is stored closer to the end user, making most operations faster. (Replica servers actually make read-only operations a purely local affair.)
P4Sandbox, as a tool for the end user, fits a different niche, but still helps in this...
Jun 06, 2011
Nothing cements customer loyalty like coming through for them in a pinch. That’s what happened when Perforce support and development was able to implement a reference solution for Research in Motion (RIM) in just two weeks.
At the 2011 User Conference, Shannon Mann described his five-year odyssey of improving performance after his company’s use of Perforce grew to embrace automated parallel builds and dramatic increases in continuous integration. By 2006, facing severe performance problems and having exhausted all hardware options, Mann’s team made the decision to split their depots.
Multiple challenges loomed, but one was a showstopper: Perforce integration with the bug-tracking software was simply not scalable. “On the Perforce side, it can do 100 jobs per minute. On the bug-tracker side, it’s 12 per minute,” said Mann. With 9 million commands per day across multiple Perforce depots, delays of several seconds per command quickly add up, and the inability to speed up bug tracking looked to derail the project.
“...
Feb 08, 2011
Would you like a faster way to promote your code than p4 integrate and then a p4 resolve -at? If so, then check out the new "p4 copy" command in 2010.2! It does the whole process without looking at integration history.
As a nice side benefit, it will make sure you are getting a correct promotion without having to do extra diff steps after the integrate to look for ignores in the integration history because it is doing the integrate based on diffs between the two branches. A great new 2 for 1 command. Performance and less work to do a "copy up" integrate.
One important caveat is that if you rely on 'p4 changes -i', 'p4 fixes -i' or 'p4 jobs -i' to verify bug fix propagation, you should not use 'p4 copy' for branching or promotion. The other is that 'p4 copy' only operates on files that don't match. So after 'p4 copy', you might find that a 'p4 integ -n' (or 'p4 interchanges') shows changes still needing to be integrated.
Feb 02, 2011
With 2010.2, you now have an easy way to maintain a DR server for your main Perforce server. Here is a quick overview on how to set one up:
Configure a second server exactly the same as your primary server. Same volumes, Perforce settings, everything. This is essential for making sure that all your triggers, depot mappings and everything work on the DR server.
Now you are going to create all the required entries in the configuration table on the master server as follows:
(Note: these commands must be run as a super user, and they are example commands only since you have to modify certain parameters for your environment.) p4 configure set replica1#P4PORT=1666 p4 configure set replica1#P4TARGET=masterserver:1666 p4 configure set replica1#server=3 p4 configure set "replica1#startup.1=pull -i 1 -J (location and prefix of rotated journal)" p4 configure set "replica1#startup.2=pull -u -i 1" p4 configure set "replica1#startup.3=pull -u -i 1" p4 configure set "replica1#db.replication=readonly" p4 configure set "replica1#lbr.replication=readonly" p4 configure set replica1#serviceUser=service (Set the security for all servers to at least 1, ideally to 3. This...
