---

[Ofer Goren is the pen name I choose... no, he's the guy I hired... you see, I'm on hiatus... (Sigh) I should really start writing in my blog. This time we get a glimpse into the process of turning simple code into the products we all know and love.]

We’ve just released a new version of the SIP Developer Suite. In the following post, I will try and describe the different steps required for such a miracle to happen. After you’ve finished reading, I hope you will have a better understanding of what we’re doing here, while waiting for our crops to grow in the farm.

Step One: Developing New Features

This is the obvious part. It starts with our Product Manager randomly selecting some features, out of those RFCs or drafts for RFCs on the IETF site. Then he tells us something like “after carefully reviewing the market, and while visiting every single customer we have, I’ve decided that our SIP suite must support…” these features. “Make it so, Number one!”

In this version, for example, we added support for RFC 4662. It is a very important addition, that deals with processing of… um… some sort of… and also with… and that too. Another thing we added is support for Android OS, as I told you before. And some new headers that were added as part of the 3GPP initiative.

Once that phase was finished, the real complex fun started.

Step Two: Compiling on all Supported Operating Systems and Testing

I mentioned several times the fact that the SIP suite supports many OS – from Microsoft Windows with its different flavors to embedded OS, such as VxWorks, PSOS, Nucleus and a lot of others, and even some real strange ones, like the Mac OS.

Once we finish developing, it is time to check our code and verify that everything is compile-able at least. The fact that we have an OS-agnostic layer helps, but there are still differences that should be taken care of. OpenSSL, for example, has different const-qualifiers in some functions for VxWorks comparing to Solaris due to different versions installed with each. Tcl/Tk has similar issues.

Testing is a very important thing to do. Or so they say. I’m still waiting for a proof. However, till then, we’re testing. And that means running every single sample application we have on various OS. Then, we run our internal multi-thread tester to check for appropriate multi-thread behavior. While doing that, we use our test application to test new features as well as regression testing.

Of course, our QA team is also in the loop, sticking their fingers inside our precious code, finding all those things we deliberately put in there to see if they find them.

Step Three: Compilation Flags – fun fun fun

Reading through our readme files, one can see that the SIP suite has a nice list of compilation flags to suit various needs and features. IMS, SIMPLE and SRV are only some examples. Compiling with all the combinations available can be quite amusing. On a slow PC, it can even be a good excuse for a day off. If you want to cause one of us developers to develop an acute case of heart disease with high blood pressure, ask him to compile with NO_TRHEADS and NO_LOGS. Then, ask him to fix all the resulted warnings. Its kinda funny to see someone with steam coming out of his ears.

Step Four: Documentation

When talking about “documentation”, I do not mean inline documentation. Like every other good programmer, we are documenting as we write our code… ahmm, right. But then, we need to put them on the .chm files, .pdf files, release notes and readme files, and send them for review to our technical writer, and then fix everything after she finds out that English is the only language we are NOT using. At least, not the one spoken in the civilized world. Then, we put those fixes in the inline documentation again, re-compile everything just to verify we didn’t accidently comment-out main(), see something you forgot to pass on, send it back to the tech-writer, and so forth. At that point – usually three days before the release – you might see our tech-writer lurking the corridors holding a knife, hunting the last person who sent her those last minute additions.

Step Five: Packaging

Linux code is tar-ed and gzip-ed, with the source code CR’d. Windows code is zipped, with the source code CRLF’d. Common-Core is a separate package. SigComp as well. As is IMS, SIMPLE, etc. You get the idea. Everything should be packaged according to its designated OS, with only the relevant files (no point in packaging an MSDev vcproj files for Linux compilation, right?), and with the appropriate compression tool. We have a script for that, but this script should be updated every time a new module is added, whenever a new OS is supported, and whenever we feel bored and want to play with it a little.

So we package, and then un-package and test the results to see that everything is compiling and running. Of course, it fails dramatically, and we need to debug the script to see where we messed up, re-package, and again. And again. And again.

Once all is working, always on the last minute of the last day of the promised Q, we ship it.

Step Six: Vacation

Yeah, right!

Conclusion

There is no moral in this story. Just a description of what I was doing since my last post here. Like always, it was a stressful month. Now that I got Tsahi off my back, I’m off to the beach.

And when I’m back, I am sure we will organize things here a bit better for the next time. I will mention that in the kick-off meeting…