Workflow on the 2-person Recordings project

Hi everyone. Today I'm going to share the workflow we use on our project. Mostly for reference, I'll come back in a year and see how things change. Hopefully we'll be on other projects by then.

So let's just see the process for fixing a bug and deploying the fix to production. That will go through the entire process.

Step 1: Observe the bug happening

The bug I'm talking about is the canned graphs problem. Certain types of graphs showed this result:

The Undesirable Result

Great. After confirming that it's a Real Bug and not just user error, I create a new ticket on our bug tracker, Unfuddle: 

The bug report: You can see it's "fixed," that's because this is a current screenshot. 

 Step 2: Reproduce and isolate the bug with tests

In general I try to trap every bug with a unit or integration test. This particular bug had a good 'integration' test case for it, but I also wrote a UI test with Selenium

You can see that I'm exciting about Selenium because I used the phrase "real live selenium ui test."

Step 3: Bug fix

The build jobs that run during merges

The actual bug fix in this case was trivial (see the post mentioned above). After making the fix, the changes are merged from my dev branch into the Test branch (our main 'stable' branch). This merge is picked up by the build server, which builds the project, runs the tests, packages it into a WAR file, and archives it.

Step 4: Deploying to production 

Jobs running for Production

Once the build is good, the next step would be more thorough manual testing to determine any tweaks, additions, etc. before we stop working on the feature. In this case though, we can just merge to our Production branch. 

Now the fix is ready to deploy, so we can run the "Production Deploy" job. This will upload our WAR file to the live server which tomcat will automatically redeploy. After running "Production Status" to confirm the website is still running, we can visit it to confirm it's working.


Well, that's pretty much it! The process is more exciting for new feature additions, but it's basically the same process. Check back in a year to see how the process changes....

The joys of automating your build and deployment

Hi everyone,

Alright, so you know like everyone I'm sure (if not, start) I like to browse stackoverflow and it's more subjective version programmers. Take a look at this question about the benefits of nightly builds for a one man team.

Having gone all these years on my own projects without a real build server setup -- I can say that I would never hesitate to use one for a non-trivial project, whether it was just me or N other people. Now the post above is about "nightly builds," but the precursor to that is an automated build. After that, you can run it nightly or by the hour -- there's no difference.

For me, using a tool like eg. Hudson makes your life a lot more easier. It guarantees you have a "working", reproducible copy of your project and if you want ready for deployment. It allows you to do other fun things like run your unit/integration tests on SCM changes (because you will forget!), run static code analysis tools and other metrics, and see trends over time.

We (my friend and I working on Recordings) have a separate Amazon EC2 instance running Hudson 24/7 just for that purpose. Our project is (relatively) tiny and there's only two of us. We've spent some hours setting it up -- and I wouldn't hesitate to do it again. We have it doing all kinds of stuff, such as:

• Monitoring our dev branch for changes; building and running unit tests whenever a change is detected
• Monitoring our production branch for merges (which have been previously tested); building, running unit and integration tests, minifying js/css code, and packaging the project into a WAR file for deployment. 
• Jobs to synchronize our local test databases with the production database
• A job that polls the website every so often to make sure it's still online
• A job that runs findbugs and compiles tasks (ie  TODOs) in source code
• Lastly: a job that deploys the last successful build from production to our production server

 We use this Hudson tray tracker tool to see the status of everything at a given time, so we always know what's going on.

This allows us to be as lazy as possible, because the last thing you want to do is waste your time manually going through the build process when you're trying to fix bugs or merge new features!

And finally, as I said I find this useful even for solo projects that still have actual users* (other than yourself). Having your CI server able to build your application, create installers/docs/etc., and generate a setup file ready for distribution is very handy and will save you lots of time.


* I've used Hudson for the Recordings java webapp and some smaller C# desktop applications.