Over the last couple of years I have released a bunch of libraries under Open Source licenses, usually on Google code. However the my last project, OpenPyro was a little different and was released on GitHub with Git as the Version Control System. I write this as a developer with more experience and comfort using Subversion and yet encourage you to release your open source projects on Git.

So what is Git? The one line description (from Wikipedia) is “Git is a distributed version control system, born with the fundamental mechanisms making branching and merging really easy.” A detailed description of Git is beyond this post but the Wikipedia page is a good place to start.

Releasing OpenPyro on Git was not an easy decision to make. The project represents a lot of work on my part and I am nowhere near as comfortable yet with Git as I was with SVN. I definitely did not want an unfamiliar Version Control System deter possible contributors to the project. However the fundamental philosophy of Git was what finally won me over.

The Git workflow is kind of new (at least to me). A developer working on a project begins by forking the core repository. He can commit code to his fork at his whim and needs to keep merging from the original branch to get the latest updates from there. Its up to him to merge changes from the core repository as they happen. People working on different forks merge changes from each other as they see fit (if you are working in a non-distributed environment, you can all merge off of a source of truth repo)

Forking basically allows the project to achieve velocities greater than the initiator of the project. If tomorrow I stop working on OpenPyro, there could be a fork that has developers more committed than I could be. Why should OpenPyro stall just cause the original developer may have.

As of right now OpenPyro has been forked a couple of times. The first fork was for a Haxe port and this was before OpenPyro was on GitHub so it wont show up on the network graph on Github. The second fork was by Kelvin Luck who fixed a few bugs on his branch and is adding new functionality there. However he didnt have to wait for me to commit his changes into OpenPyro head. I merged his changes into the OpenPyro head much later. And now the OpenPyro history shows his additions to the project as official commits.

The diagram below shows the state of the repository as it got branched and merged at different times.

This kind of collaboration wasnt possible with SVN, something I realized while working on LogBook. I would get patches for bugs on the project, sometimes feature updates I didn’t much care about. But it was up to me to add those in, and sometimes time pressures made me miss commiting some features forcing the developer on the other side to wait with probably changes local to his machine.

I have been on the receiving side of that as well and I am sure you have as well. How many times have you looked at an open source project that seems to fit the bill for what you are working for but comes up slightly short. What do you do then ? Do you fork it? Without commit access to the core repository that the original author is maintaining, you cannot branch the project. All you can do is export all the files and recommit them into a new repository that you control. But now you have lost the project history (plus something about this approach just smells wrong, with very little attribution on the “forked” repository to the main project).

There are other features that are great in Git. Offline commits is another great feature that I use quite a bit. A more detailed comparison against SVN can be found here

Whether this paradigm works as well within teams working together, I am not sure. At work we continue to use SVN right now and I am not sure if we plan to move off it anytime soon, But if you are a developer releasing code under open source, I strongly encourage you to try Git. In the meanwhile here are some resources that you could find useful. Linus Torvald’s talk at Google is a good place to start understanding Git philosophically.

Git Manual
GitCasts: Videos on using Git
Getting Started with Git docs on OpenPyro

I have been using Flex Builder for a while now as my main Actionscript IDE for both Flex and Actionscript projects. Of course in the latter, I have been very sensitive to not using even an iota of the Fx library. However traditionally I had always used the [Embed] metatag to embed graphic symbols into my Swfs. What I did not realize was that the Embed tag brought in Flex code into my project. I only discovered that as I was getting a build of OpenPyro ready for a release (its going to be 0.4, isnt out yet, but probably early next week).

I was trying to build the OpenPyro swc that users could be imported into projects. However running the compc command resulted in the following error screen:

Apparently, using the Embed metatag was causing the graphic to be imported but then converted to an instance of the Flex SpriteAsset class. WTF, this was definitely not what I wanted. Googling (at 2 am, so I may not have used the best queries) did not bring in any meaningful results. However a friend of mine recently switched from Flex Builder to FDT and I remembered him showing me how he did it, so here are the steps:

1) Create MovieClip symbols in the Fla and export them for Runtime Sharing with appropriate class names.
2) Generate the SWC from the Fla
3) Place the SWC in the classpath of the Actionscript project.
4) Use the exported symbol’s class name to reference the graphic symbol

So this worked. I was pretty aware that the Bindable tag was Flex specific but I didnt know that Embed tag did as well. Adobe really needs to differentiate the Flex specific metatags like Bindable and Embed with the pure AS3 ones like Event. My one big complaint with Flex Builder was that it never complained considering I was in a pure Actionscript project.

I hope Gumbo fixes this.

The last couple of weeks I have been caught in a couple of conversations around application versioning and build systems for Flash and Flex. Once for example, the context was a list of bugs from a QA build of a Flex project that we could not reproduce, and were not sure of the version of the swf that QA was seeing. We had checked in our latest swf that was part of a Java war that was to be deployed to the site, but there was no way to confirm that the version in QA was the one we had checked in. Another time, we were fixing up a swf that actually did have a version string that was integrated into the context-menu of the swf. However, this version was not tied to any particular logic and the developer was free to increment/decrement versions as he saw fit. And of course there are purists who feel strongly that we should have a build system because all the other “serious developers” have it.

FAIRLY OBVIOUS WARNING: A lot of this post is fairly obvious if you have worked on big projects that have a life of more than 1 or 2 releases (more so if you come from a language with an already established build tools like Java or C#). However this doesn’t seem to be the case with a lot of Flash and Flex developers who are often called to do quick projects. This is more for teams like mine where we work on diverse projects are often jump from one to another. Sometimes we have to work on stuff we did a while back and now there is one new feature thats needed but in the meanwhile dependent libraries have changed.

Because of the lack of any robust, easy-to-setup build and unit testing systems, they have traditionally been considered nice-to-haves but not really available if you have a deadline looming. Ant and FlexUnit are definitely available but why isnt FlexUnit integrated into FlexBuilder with one click “Run Tests” button ? For example, here is an image of JUnit as integrated into Eclipse:

This may be changing slowly though. I think Flex Builder now comes with a template ant build setup in one of the install directories, but its still upto you to set it up on your environment.

So here are a list of issues I deal with on a fairly regular way. I have a few solutions but if anyone has other ideas, please leave me a comment.

1) Identifying a live application:
When you are evolving an application or have QA builds going out fairly regularly, there is a big need to be able to verify what build is in front of the end user / QA engineer. For example, we have had caching issues when even after we have deployed a swf, a few users still see an old version till their browser expires it. So if I get a bug filed on my application, I want to make sure of the version its being filed against. Context menu integrated version strings seem to do this job pretty well, and its something I feel all applications should have. On a recent project this saved quite a bit of time since some network issues were preventing the latest build from actually reaching a test server and it was really easy to verify the build was wrong. One technique we adopted was an idea taken from web services (most webservices are accessed using a url that includes a version, for example facebook’s apis are accessed via a url like http://api.facebook.com/1.0/). So using the same idea, we now compile so that output swf’s name has a version string appended to it. For example we may have player_1.2.3.swf (or release swfs to folders like …/v1_2_3/player.swf). This lets us check version via html and also keeps a history of previous swfs in case we have to revert to one in an emergency, or check if a particular issue in the current live build existed in the previous build as well.

There is a blog post on the SVN based version context menus here

Whats interesting is I have such an easier process when I release code on this blog. With a simple “enable view source” option, All the code gets packed into a downloadable zip file and the context menu item is appended to with the view source option that takes me immediately to the source of the current swf. I wish this concept could be extending to target svn repositories and app versions.

2) Getting back to the source of the code from the swf
The preceding conversation immediately brings to light another requirement: Once I do know what version a bug is on, I should be able to check the code out for that version and build it. One thing I am trying to prevent is a swf that may go into production built of code on a developer’s machine that he may then forget to check in. Ideally the application version should be tied to your source code repository in some way. Although I am nowhere near this yet, ideally, the action of compiling your swf should trigger a checkout from the repository first and the swf should be built of THAT code. And in a perfect world, I would live the SVN revision number to be available in the application version.

This problem becomes a lot more tricky when you may have different versions of an application running in different places. If you are building a generic swf for example (like a photo browser application or a video player that may love on different environments). How do you know which version of the swf is running if the last time you deployed to that environment was like 8 months ago.

3) Controlled Refactoring
Honestly speaking, historically, build systems were always considered nice-to-have for our projects. Developers on a project have a pretty good idea how to get their application to build by hitting the compile icon on Flex Builder. But that breaks down if you have ANY dependency on any other library. For example, there are more than a couple of libraries that we have common among different applications. However if anything needs to be changed on a class in one such library, after the change is made, the developer making the change must ensure that the change didnt break anything on any of the other applications that use that as a dependency. To do that within the context of Flex Builder is virtually impossible, would you open every project and compile it ? At this point it becomes imperative that all your dependent applications have tests that can be triggered with one click when a core class is changed.

The need for Release Engineers
Our other projects have release engineers whose main job among others is to check out code from the repository compile it and then deploy it to the test environment. Here is a quick snippet from Wikipedia:

The responsibility for creating and applying a version numbering scheme into software–and tracking that number back to the specific source files to which it applies–often falls onto the release engineer. Producing or improving automation in software production is usually a goal of the release engineer. Gathering, tracking, and supplying all the tools that are required to develop and build a particular piece of software may be a release engineering task, in order to reliably reproduce or maintain software years after its initial release to customers.

I encourage you to read the entire article here.

These are a few thoughts and ideas I have right now. In the last few weeks we have made a lot of progress towards a mature build and deploy process for Flash based applications. In the meanwhile if any of you readers have a good release system built and that you use regularly, please drop me a comment here and I would love to have a conversation with you on your system. I know there are a few interesting projects out there like antennae, but if there is anything else anyone can recommend, please let me know.