4 Replies Latest reply on Feb 7, 2009 3:30 PM by Clifford Meece

    version control and deployment strategies

    Clifford Meece
      Hi,
      I was looking for input from the community on general strategies for using version control and managing deployments to test/stg/production.

      Currently, I am using subversion to track my source code, and using the standard flex builder build routine to produce my binary output and test. My output is stored locally on a shared vmware drive, so that it can be served up with a linux vm running apache (this is not dissimilar to just local testing)

      Now I'm getting ready to deploy to some remote testing server though, so I'm trying to think of the best way to go about it. I would like to tag my code in svn with a release tag, as is my practice in other platforms. Should I also store the bin folder in svn? Should I check in the resulting binary code independently in a separate repository/directory and then tag it there? Should I create a new build target to deploy directly to my testing server?

      The issue with the tagging approach seems to be that if I want to rebuild the code or redeploy it for any reason, I would have to checkout the tagged code in a separate directory, import it as a new project, rebuild and then redeploy.

      If I checked in the tested binaries into a separate repository/folder, I could always just do an svn export for deployment, but I'm not sure if that would cause any weird issues, and it seems a bit wasteful. I suppose I could build from the tag and zip up the resulting release and just make it available via normal download, but it seems that I would likely then have lots of working directory checkouts as flex builder projects for each tag or release, just so that I could rebuild from them....doesn't seem very elegant.

      I'm very interested in hearing any feedback on this. How do you do it?

      thanks,
      Cliff
        • 1. Re: version control and deployment strategies
          levancho Level 3
          usually I never store binary code under version control, it just does not makes sense, most of the time you tag the source code before building if you want to have production release or something like this, you cvanalso do automatic deploy with ant so that it builds release, tags it and then deploys it with one shut,and updates release notes if you want to as well :).

          quote:

          The issue with the tagging approach seems to be that if I want to rebuild the code or redeploy it for any reason, I would have to checkout the tagged code in a separate directory, import it as a new project, rebuild and then redeploy.
          I am not sure why you have to checkout again, you can always switch to tagged version build it, and switch back if you want to,
          • 2. Re: version control and deployment strategies
            Clifford Meece Level 1
            good point...i didn't see the 'switch branch tag/option' earlier. That certainly makes it a bit easier. I normally don't keep binary targets in svn either, however, that is usually for desktop deployments. Since the deployment target in this case (ignoring air for the moment) is to a web directory, I thought (for half a second anyway) of managing deployments of my packaged bin directory to my production web server via svn export, or svn update. That is not an uncommon practice for deploying php apps, or django apps. granted they are mostly text files, but the process is the same.

            Do you have any docs or pointers on using ant with flex builder and how to define production release targets etc? I am a total newbie when it comes to ant.
            • 3. version control and deployment strategies
              levancho Level 3
              flex with ant is still not very very popular combination,since FB does all for you anyways, but I have to say ant is lot more flexible, especialy if you combine it with FB, ant can do pretty much anything, ...
              here is link about flex's ant tasks
              http://livedocs.adobe.com/flex/3/html/help.html?content=anttasks_1.html

              most of the projects I have done in Flex were with ant,

              here is general approach:

              for internal testing I let flex builder build and deploy within integrated tomcat,this is also where I do debugging, FB is pretty good about that.

              then I have following targets :

              build target - builds optimized version of flex app, only using library classes that are needed by project, also using that to feed my Modules building tasks so that they exclude all class references (like Button, Tabnavigation etc... ) from their compiled units,
              something like this (this is my old fb2 example) i don't have fb3 example handy right now :

              quote:


              <mxmlc file="${basedir}/main.mxml"
              debug="false"
              optimize="true"
              output="${dir.web}/main.swf"
              show-binding-warnings="false"
              show-actionscript-warnings="false"
              link-report="${basedir}/docs/my-links.xml"
              use-network="true">
              <load-config filename="/configdir/modified/flex-config.xml"/>
              <source-path path-element="${FLEX_HOME}/frameworks"/>
              <compiler.library-path dir="." append="true">
              <include name="lib" />
              </compiler.library-path>
              <compiler.source-path path-element=""/>
              <compiler.source-path path-element="src"/>
              <metadata description="some app">
              <contributor name="John Doe" />
              <contributor name="Apple Orangino" />
              </metadata>
              </mxmlc>

              <!-- compile module mymodule-->
              <mxmlc file="${basedir}/mymodule.mxml"
              debug="false"
              optimize="true"
              output="${dir.web}/mymodule.swf"
              show-binding-warnings="false"
              show-actionscript-warnings="false"
              load-externs="${basedir}/docs/my-links.xml"
              use-network="true" >
              <load-config filename="/configdir/modified/flex-config.xml"/>
              <source-path path-element="${FLEX_HOME}/frameworks"/>
              <compiler.source-path path-element=""/>
              <compiler.source-path path-element="src"/>
              <metadata description="some app">
              <contributor name="John Doe" />
              <contributor name="Apple Orangino" />
              </metadata>
              </mxmlc>



              tag -target tags release based on parameter of latest tag plus number increment I configure in properties file.

              Utility targets :

              classpath target - builds classpath string for compc task.

              commit target : commits source code, before building.

              resources target - copies all resources files to build directory,

              deploy-local target- deploy to local Integration server

              deploy-remote target deploy to remote uat server.

              test -target - run test cases over classes and generate report.

              and of course all famous asDoc target :)

              good thing is that you can create "ant builder" under project properties and chain your targets with flexbuilder's build commands,

              you can also easily integrate with build servers ( I use hudson)
              here is example : http://hudson.amostudio.com/
              MR hudson checks out code for you, builds it using ant targets you tell it to use, and reports to you, its pretty cool and very handy to always have active build proccess over codebase, of course in some cases its overkill, but most of the times, MR hudson is good to have.

              unfortunately all my ant files are for external clients I cant disclose them, but I can write blog about some general (apples and oranges) example, hhm that's actually good idea :) I can shake off some stress as well :)
              thanks for the idea :)

              hth
              regards
              levan
              • 4. Re: version control and deployment strategies
                Clifford Meece Level 1
                incredibly helpful, thanks. There's a lot here for me to chew on; I'll dig into this a bit more later. I'm looking forward to the blog article!