Nobien

Matt , July 19th, 2010

In the previous part of my series "Practicing Continuous Integration on Flash Projects" I described how to setup a CI server using Amazon's EC2 service. In this final part of the series I'm going to quickly show you how to set up your project in Hudson so that it can build it.

Using Hudson

If you're practicing CI properly you should be integrating new code on a pretty regular basis. When new code is integrated the project should then run through its build process which should include running all the unit tests and building the project if all the unit tests pass. This is where Hudson comes in. Hudson can monitor your source repository and whenever new code is committed it will retrieve it and build the project. Now I'm going to show you how to set up the CIExample project in Hudson.

Read the rest of this entry »

ActionScript 3, Continuous Integration, Flash, Flex, Methodology, Process, Unit Testing No Comments »

Matt , July 19th, 2010

In the previous part of my series "Practicing Continuous Integration on Flash Projects" I explained how to use Apache Ant and the Flex SDK to automate the build process of a project. In this part of the series I'm going to show you how to set up Hudson, an integration server, on a bare bones Fedora 8 Linux box.

Introduction

Code integration happens whenever you commit code into the project's mainline. There are essentially two camps when it comes to building the project after new code has been committed. Some developers prefer to do it manually, meaning that the developer switches to the "integration machine", checks out the new code and runs the build process. If the build is successful then the developer's commit is also successful. If its not successful, then the developer should revert their commit, make adjustments to their code, and attempt to integrate again later.

The other camp enjoys using a CI server such as Hudson or CruiseControl. A CI server will monitor the project's mainline and attempt to build the project any time new code is committed. A developer can check out the CI server website to see the progress or the eventual status of the build. When the build is complete, successful or not, the CI server should notify the developer who committed the new code. Personally I think a CI server is an invaluable tool when it comes to practicing CI and thus I'd like to show you how to get Hudson up and running.

Read the rest of this entry »

ActionScript 3, Continuous Integration, Flash, Flex, Methodology, Process, Unit Testing No Comments »

Matt , July 19th, 2010

In the previous part one of my series of "Practicing Continuous Integration on Flash Projects" I explained how to set up a Flash project for CI. In this part of the series I'm going to explain how automation is achieved using Apache Ant and the Flex SDK.

Introduction

One of the most import parts of CI is the need to automate the build process. Building a Flash project means, at the very least, compiling your code into a SWF file. There are various ways to compile a SWF, but in order to be able to automate the process its best to use the mxmlc compiler thats part of the Flex SDK. If you are using the Flash IDE to compile your projects I would say that CI is not for you and/or your organization. However, thats not to say you should stop reading or stop using the IDE. I still use the IDE on nearly all my projects, just differently than I used to. Anything that requires timeline animation or is just easier to draw using the IDE I publish into a SWF. I then import the symbols from that SWF into my project when I compile with mxmlc. Explaining how to do this and just exactly how to use the mxmlc compiler is outside the scope of this blog series but you can learn more about using it on the Flex 4 product support page.

Read the rest of this entry »

ActionScript 3, Continuous Integration, Flash, Flex, Methodology, Process, Unit Testing No Comments »

Matt , July 19th, 2010

In the previous part of my series "Practicing Continuous Integration on Flash Projects" I described what CI is and its best practices. In this next part I will explain how to set up a project to make the CI process run smoothly.

Introduction

Practicing CI relies heavily on a consistent process. Having a well defined project structure will definitely be an important piece to the puzzle as well. Flash projects are unique in how they are structured and any seasoned developer has their preferred way of doing things. Regardless of if you are a seasoned developer or new to all of this, this part of my series is meant to serve as a simple guideline to developers who are new to the practice of CI. I truly believe that having a simple and consistent project structure is extremely important to being able to make a project portable and easily built on various platforms. That being said, I've created a very simple project called CIExample. Its under version control at google code. This is the project that I will be referencing throughout the rest of this series.

Read the rest of this entry »

ActionScript 3, Continuous Integration, Flash, Flex, Methodology, Process, Unit Testing No Comments »

Matt , July 18th, 2010

Welcome to my blog series, "Continuous Integration and Flash". This series is a case study of all the things I learned about practicing Continuous Integration. As a reader of this series, you are most likely interested in Continuous Integration in some way or another. After reading at least this first entry I hope to give you a better understanding of what Continuous Integration is and how its practiced. In this series I will also explain how to set up a project, automate the build process, and set up a CI server using Amazon EC2. For the remainder of this series I will mostly use the acronym CI when referring to the term Continuous Integration.

Read the rest of this entry »

ActionScript 3, Continuous Integration, Flash, Flex, Methodology, Process, Unit Testing 3 Comments »

Matt , June 16th, 2010

I've really been getting into Apache Ant lately. I really enjoy using it to manage various build processes when working on Flash projects. So when I found out that AIR 2.0 can invoke a native process I immediately thought that it'd be cool to learn how to use that capability to make an app that presents a UI for a given Ant build file and then be able to run its various targets from that UI. Thus I created a simple application that I'm calling, for the time being, rANT.

It took me a while to figure things out entirely but in the end I'm happy to have learned how to use flash.desktop.NativeProcess. Unfortunately, in order to realize my idea faster, I ignored the fact that the application would really depend on a user's system. For instance, I have Ant installed in such a way that its available as a system command so I can run it from the command line like any old DOS command. I know not everyone is setup like this andwould require knowing where Ant is installed on a user's system. Additionally, Ant doesn't come with a good old fashioned .exe file for Windows so I invoked Ant via C:\windows\system32\cmd.exe. Here's some pseudo code that comes straight from my application...

Another (little) thing was that Adobe isn't very clear about the fact that you need to package your application in a native installer in order to use the 'extendedDesktop' profile. Took me a while to figure it out, but the good news its pretty darn easy to package a native installer from a .air file.

At any rate, its by no means ready for the public, but I wanted to share my work thus far to see if anyone else would be interested in an application such as this. So here's how it looks and works so far:

When you start the application you're presented with a screen that allows you to load a build file...

Once the file is loaded it displays information about the build file and a list of its available targets...

You can then select a task and run it. Here you can see the output in the TextArea component from when I ran the compile-docs target...

Some of my targets require arguments to be passed in for them to work. For instance, my compile-and-debug target requires a debugLevels parameter that specifies the various debug levels (info, status, etc.) to output to the debugging console (which happens to be de MonsterDebugger). So I created a little panel that lets me specify parameters for the target...