On Flash/Flex build systems and application versioning

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.

On Flash/Flex build systems and application versioning

4 thoughts on “On Flash/Flex build systems and application versioning

  1. 1. I do the exact same. Context Menu version # appended to SWF name.

    2. This is impossible, don’t try. Even if you did get Cruise Control up, if you’re on a team of devs all sharing the same trunk that builds many different types of SWF’s, there is no such thing as a “common code base”.

    …however, what you CAN do is tagged builds. Aka, you say to yourself one day at 6:58 pm on a Thursday, “This damn code works GREAT! I’m going to ensure NO ONE messes this up.” You then proceed to copy and paste the entire directory into trunk, and name it “project-x-4.19.2008”. You then check in the tag.

    That way, your team can publish all they want into the trunk, but you can guarantee your good code is on ice. If you ever need it, it’s always there for you.

    Furthermore, you can’t keep track of builds unless it’s 1 person’s responsiblity. Coders, ecspecially Flash devs, have too much stuff going on to keep track of SVN. Therefore, it needs to be 1 persons responsibility and they need to have the authority to enforce their decisions on how SVN is used. If not, you’re shooting blanks, and might as well keep your own SVN repo and not share to ensure those you can’t control don’t screw up your repo.

    3. Same problem here. However, keep in mind the reason most Flex 2 apps (charting usage non-withstanding) were so easy to re-compile in Flex 3 even with tons of changes was because of the standard API.

    If you define a good API up-front for your library, with no slaves to the base class, you should be good to go. Granted, you’d still have to test for bugs, and hopefully ALL projects would have tests, but if there are none, the best you can do is test yourself manually.

    Please keep in mind every time you say “Flash” vs. “Flex” I assume you mean “insane deadline prevents best programming practices” vs. “we can make time for them”, hehe! That’s been my experience; the Flash related work just doesn’t have the reasonable deadlines to implement such good practices.

    Like

  2. @JesterXL
    Good points all. On the Flash vs. Flex, I dont think I said Flash vs. Flex at all, to me its pretty much the same, one just using a third party swc and another not. We walked away from the timeline a while back (thank God!). But yeah, at least with Flex you have ANT and such to (try to) use. I tried building a jsfl based build system at one time that went nowhere. And with programmers moving towards Flex Builder, any chance of good practices in that domain have gone bleaker 😉

    Like

  3. […] the context was a list of bugs from a QA build of a Flex project that we could not reproduce, ahttp://www.arpitonline.com/blog/?p=131OMG and Eclipse Announce Program for Second Day of the Symposia On .?Open Software & Standards […]

    Like

  4. […] On Flash/Flex build systems and application versioning | code zen Apr 19, 2008. Context Menu version # appended to SWF name.. If you define a good API up- front for your library, with no slaves to the base class, you should be good to. We walked away from the timeline a while back (thank God!. – On Flash/Flex build systems and application versioning | code zen […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s