To Perforce or Not To Perforce: That is The Question

As the world keeps spinning and technology keeps progressing ever-further, a lot of focus is being put on optimizing productivity. However, there is an aspect that is being overlooked: adaptivity. Being adaptive as an organization has become critical. It’s not just about your organization, but about helping your clients to be fluent and adaptive as well. In our experience, this means helping the user to get the best experience possible. We figured it’s a pretty simple equation: happy user, happy business.

So how do you achieve this? We’d like to share with you some insights we learned on a journey to helping one of our clients. To give you some background information, this client has been using Perforce to manage their code for quite some time. While deploying Rookout with our customer’s environment, we understood that the customer wouldn’t be able to package their sources into its application’s environment. Not having the sources packaged with the application means that Rookout won’t be able to verify that the user is using the right source code files when debugging. So when they hit this snag in the road – and quite a large one at that- we figured it was time to step up to bat and figure out how to make their lives easier. We decided that we wanted to support sources auto-fetch for customers who use Perforce. Here’s how we did it.

The Beginning

The story begins in the not so far off past, where our clients found that they had a problem in which they couldn’t package their applications sources, and due to that issue, weren’t able to know for certain if they were working on the right version of their code. Usually Rookout is able to provide the right version of code, because when the client adds the version ID during the build process, Rookout then brings the right version for the chosen app.

In Rookout we’re trying to reach perfection. We wanted to make sure that our client wouldn’t have any issues and would get the best experience possible. As we as humans are prone to error, sync issues might be experienced here and there. We wanted things to feel and work as best as they could.

The Investigation

As the situation came to light in the Rookout offices, we decided that we wanted to help them connect to their source control and aid them in debugging the right application with the right source code, no matter what. This is when it all went downhill for me.

We began to investigate what Perforce is used for and how to use it. Perforce is a source control service meant to be used in large organizations with a lot of code. As such, Perforce, as a tool, is meant to only be used internally and therefore does not provide what some SaaS git services do, such as a ‘Rest API’. This means that I am unable to go from the browser straight to Perforce. For example, if you work with GitHub and ask it for the code, the browser will ask the server for the code that you specifically wanted and it will go straight from the server to the browser. Comparatively, Perforce doesn’t allow that, nor do they have any kind of API for that.

So the team sat down and started brainstorming all the ways we’d be able to work around it. Rookout’s desktop app is already installed on all of their personal computers as they use it before they use our Perforce integration. Therefore, we decided to work with Perforce’s CLI (Command Line Interface), otherwise known as P4.  After approximately a week or two of work we were able to get a working product in our local environment. We sent it to them to try out and – major shocker here (sarcasm intended)- it didn’t work. Thus began a very long debugging process.

‍

The Process

When debugging, we experienced two main difficulties:

1. We couldn’t get to their servers by ourselves, as it’s in their private network.
2. We weren’t able to physically get to them, either, due to coronavirus restrictions.

We were out of ideas, when one of our client’s employees stepped up and saved the day. He offered to run it on his computer and work with us to figure it out by advancing from session to session, one stage, and one hour (and often quite more) at a time. Here are the stages we went through:

1. We couldn’t connect to the server and found that it was sending the server the wrong users.
2. Instead of asking for just one file (such as what Rookout does on Git services) we asked to get all the files from a specific library (depot), which caused major performance issues.
3. We succeeded in fetching a list of the files in place of the files themselves. Then, we got stuck because P4 reported that it had retrieved the file for us. This was true enough, except that the files in question were empty. So, story short, we didn’t succeed in getting the file we needed.
4. We worked very closely with our partner to ultimately solve the problem for now and forever, amen. It took another two hours but we finally fixed it and then made it into an official version.

Once these steps had been completed, we gave the customer that new official version and told him to try and run it. He said that it didn’t work, and I swear my heart stopped for a millisecond.

Then the customer checked he had the latest update and lo and behold, it finally worked! I felt my heart begin to beat again and the weight of the project fall off my shoulders.

Rolling with the punches

So, to make the story short, good relations with customers are the key to giving them exactly what they need and want. During this whole process, I found out the hard way that while you can do whatever you want in your closed test environment, though once you get out into the big wide world, it’s unpredictable and it might not go as well as you’d hoped. However, this is easily fixable: just remember that being adaptable and fluent is the key to success. (Side note: it also doesn’t hurt when the client is outstanding and goes to great lengths to help you help them). Aka- just roll with the punches as they come and everything else will ultimately fall into place.