June, 2008
The trouble with using an empty development database
Submitted by Matthias Marschall on Thu, 06/26/2008 - 21:16Imagine yourself building a new web application from the ground up. Let's say - an online bookshelf where you want to keep track of all the books you own. Along with the first lines of code you setup your basic database schema (You really need a database, right?) and you even come up with some nice demo records for testing. You're making great progress building features into your app, and the sun is shining brightly on your brand new Macbook Air (ok, if the sun shines so brightly you may have trouble seeing your screen - but, let's ignore that now for the sake of the story). The web application framework you chose takes care of all the nasty details of dealing with the database and your application is a pleasure to use.
One day you decide to take it for a spin by loading up all the books collecting dust on your shelves. It takes a while to fill it up and somehow you can't ignore the fact that it gets a little slower over time. After entering a couple hundred books (have you really read all of them?) you start wondering what's wrong with your box as your app begins behaving strangely. It feels like its literally crawling between pages. It can't be your code, right? You didn't do anything wrong, did you?
Ownership Takes Commitment
Submitted by Dan Ackerson on Tue, 06/24/2008 - 09:05Building on my previous article "The Branch Not Taken", I'd like to convince you of the importance of code ownership. In Garret Hardin's essay "Tragedy of the Commons", he describes the burden that communal freedoms place upon a finite resource.
Protecting your release branch
If you consider stable, production ready code as a finite resource, it naturally follows that granting everyone write access will slowly, but surely, degrade its worth. So, in the interest of keeping your release branch in a pristine state, you're going to have to remove write access to the release branch (or trunk) from your developers. Pretend you're putting up a fence around your codebase. But it's not just any fence, I'm talking about a six-foot high, chain-link fence with a locked gate.
The "It runs on my box" syndrome
Submitted by Matthias Marschall on Thu, 06/19/2008 - 22:43You've heard it before, right? The standard answer given by so many developers when faced with a broken feature on the test server: “…but it runs on my box…”. Oh yeah, one of my favorites. You're supposed to get this released and they can only come up with this lame excuse.
Why does every developer on the planet answer in this same way? It's probably safe to assume that, indeed, it does run on their box. So what's the real problem here? The developer wants to see his feature running live in production just as much as you and the product owner. Now you tell him that his code doesn't even run. Even if you didn't intend to blame him, he'll always interpret it that way. Because his brainchild does not perform, he takes it personally. He really put a lot of effort into designing and coding. He created clean, tested code, and made sure that his feature really delivers what the users need. After weeks of effort, you come back to him and say that it doesn't work. Such motivation killers don't exactly create a healthy work environment, much less foster professional respect.
The Branch Not Taken
Submitted by Dan Ackerson on Tue, 06/17/2008 - 22:35Whether you're running your website from the trunk or a release branch, you've already taken the first important step - you're using a source code repository. Depending upon the size of your team and website, the way you manage this repository will vary tremendously. I'd like to share some of my experiences in managing code repositories - a must-have skill set for agile web development.
Development branches vs. stable, protected release branches
Creating development branches has certainly become mainstream nowadays and there are plenty of articles out there which explain merging techniques. While I've heard a lot about stable, protected release branches like the Mozilla Foundation uses for Firefox, others often type cast the trunk into a "sand-box" role, open for any quick and dirty commits. For this reason, the trunk is commonly accepted as "bleeding-edge" - to be checked out and deployed at your own risk.
Sample Code for the Mingle API Using Ruby on Rails ActiveResource
Submitted by Matthias Marschall on Thu, 06/12/2008 - 20:57We use Mingle for managing our agile software development process and found some repetitive tasks which we wanted to automate.
As part of our deployment to the test environment, we had to manually move all "ready to deploy" stories to status "deployed on test env". With every release to production, we had to move them all again from tested to done. Then, we carefully copied all story numbers and titles to a Release Notes email, which was sent out to all interested parties within our company. Not exactly a lot of hassle but we did it often enough (and found it boring enough) to think about automation.
What Sysadmins Want
Submitted by Dan Ackerson on Tue, 06/10/2008 - 20:40Most of us have seen, or at least heard of, the Mel Gibson movie "What Women Want". It certainly is a tantalizing idea - being able to read the thoughts of other people. Now being able to read your sysadmin's mind may not be at the top of your wish list, but, I bet there were a few times it sure would have helped fathom the meaning of that chill stare of contempt from across the table.
Or, I could just tell you what they’re thinking. For starters, what will be the production usage of that new feature you’re developing? Now, I know you're not Nostradamus - but, you've thought about this, right? Any idea how many additional web server requests per user or session? What about the performance overhead of those additional database queries — what's the longest running query now? Will you need to run that cronjob every five minutes or is once a week fine? These are just a few of the everyday concerns your sysadmin has while operating your company's website. Have enough respect for his work (and yours) to do a bit of homework and come up with some numbers here.
About Agile Web Operations
Welcome to Agile Web Operations - a blog to help web developers and operations bridge the deployment gap.
Nowadays, successful web development requires both solid coding and in-depth operational know-how. Writing a web application doesn't have too much in common with keeping it running, and having knowledge in both of these areas is crucial growing your online business. Whether you've split these responsibilities amongst the team, or have folks with both skillsets, you'll often get opposing viewpoints on how to solve website problems.
We want to share with you both our successes and difficulties in choosing the right advice, and help you bridge the gap between development and web operations:
- What's needed for deploying and operating your web application?
- How can you keep a laser-like focus on the most relevant aspects of your web project to ensure a successful launch?
- What will help you remain lean and agile enough to adapt to continually changing requirements without burning out?
