Comments on: On Flash/Flex build systems and application versioning http://www.arpitonline.com/blog/2008/04/19/on-flashflex-build-systems-and-application-versioning/ "I write pretty software" Mon, 26 Jul 2010 08:34:18 -0700 http://wordpress.org/?v=2.8.6 hourly 1 By: eclipse software testing http://www.arpitonline.com/blog/2008/04/19/on-flashflex-build-systems-and-application-versioning/comment-page-1/#comment-35065 eclipse software testing Wed, 30 Apr 2008 08:08:21 +0000 http://www.arpitonline.com/blog/?p=131#comment-35065 [...] 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 [...] [...] 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 [...]

]]> By: arpit http://www.arpitonline.com/blog/2008/04/19/on-flashflex-build-systems-and-application-versioning/comment-page-1/#comment-34017 arpit Sun, 20 Apr 2008 05:55:49 +0000 http://www.arpitonline.com/blog/?p=131#comment-34017 @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 ;) @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 ;)

]]> By: JesterXL http://www.arpitonline.com/blog/2008/04/19/on-flashflex-build-systems-and-application-versioning/comment-page-1/#comment-34004 JesterXL Sun, 20 Apr 2008 04:04:57 +0000 http://www.arpitonline.com/blog/?p=131#comment-34004 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. 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.

]]>