Elias Interactive

We Grow Beautiful Websites

Development

Magento SVN Usage – Best Practices

· · 8 Comments

In this article we talk about best practices around using Subversion (SVN) with Magento to help you maximize its many benefits. Anyone who works with Magento will be interested in this easy to understand capabilities and benefits overview of Magento SVN. Whether you’re a store owner or a developer, SVN can make your life easier.

Quick Summary

  1. High-level explanation of SVN
  2. Who should use SVN?
  3. Why it should be used?
  4. Specific things to watch out for with Magento & SVN
  5. Bonus: Tools for the Trade

SVN-Environment Relationships

1. High-level explanation SVN

SVN (aka Subversion) improves the development process. Its an evolution of CVS (aka Concurrent Versions System) which allows developers to maintain local, staging, and production environments. It’s best practice for most software development (and Magento) projects to utilize some type of version control system. Git is worth noting as an alternative to SVN. The main difference being that Git stores everything locally whereas SVN stores things on a repository hosted on a centralized server where all updates are pushed and pulled. Typically people either prefer SVN or Git, both have good reasons and arguments. But for the purposes of this article, though, we are laser focused on Magento SVN usage and not so much the argument between which is better to use.

Simply put, SVN is a tool that keeps a revision history of code over a period of time. You keep project code located within the repository and pull a copy of the entire code with one simple command. As people work on the project, updates to the code are committed to the repository, which allows anyone who is “linked” to the repository to sync their code with the latest changes via one click of a button. A simultaneous, multi-user environment is organized for team-based development and proper administration.

There are an incredible number of benefits to SVN… too many to mention here.

2. Who should use SVN?

Everyone who works with Magento should use SVN. As a rule of thumb, SVN should be used in any significant software development project (unless you use Git as an alternative).

3. Why SVN should be used?

SVN allows multiple developers to build simultaneously in an organized fashion with a detailed history of the progress. This ensures that the live storefront (production environment) is always intricately cared for and remains “open for business”. There’s nothing worse than an outage in the eCommerce world and using SVN with Magento helps you to hedge against such events as it relates to your code. Every developer has experienced early on in their career the inevitable mistake of removing a file via FTP, only left to realize that file is lost in space and no longer retrievable. Thanks to SVN, you will be able to recover and restore this file in no time. The developer’s life becomes easier; and your eCommerce business is safer. When used properly, SVN ensures reliability, integrity, speed, and fall-back recovery.

4. Specific things to watch out for with Magento SVN

In our experience, there are a few specifics to watch out for when using SVN with Magento. Without getting too technical, here are a few things we’ve learned along the way:

  • Watch out for the caching. Utilizing “SVN:ignore” is the key to allowing the local environment to cache correctly. I would recommend setting SVN to “ignore” for the following (at least) when maintaining separate environments:
    • /app/etc/local.xml (or use SVN lock instead for this)
    • /media/catalog/product/cache
    • /media/tmp/*
    • /var/cache/*
    • /var/report/*
    • /var/log/exception.log
    • /var/log/system.log
    • /var/locks/*
    • /var/session/*
    • /var/tmp/*
  • Create and execute test script. We’ve learned the hard way to stick to a quality test script as we merge different branches into the main SVN repository (used for production). Testing major changes in a staging environment prior to going “live” to production with the new changes can save a lot of heartache later on. Don’t underestimate testing your changes, especially with Magento’s complex architecture.
  • Create branches for project phases. Sometimes it helps to create a “branch” for each phase and a staging environment for each branch (assuming the project is large enough to call for it). This makes it easier to rollback and merge updates, if needed.
  • Keep the entire Magento directory maintained in SVN. Call us crazy, but we prefer to keep the entire Magento directory maintained via a SVN repository. We do this so that we can upgrade, modify, and perform other changes locally prior to streamlining the changes to the staging and production environments.

5. Bonus: Tools of the Trade

We fancy apps that make our lives easier. Who doesn’t? We invest a lot of time researching and trying out new apps to see how well they fit our business. So far we have found a few SVN tools that are worth mentioning. Note: some of these are Apple-specific.

  • VersionsApp: A high-quality desktop application that allows one to manage repositories locally for streamlined management of code.
  • BeanstalkApp: A sweet as online SVN storage service to host repositories full of code, revisions, and a great interface for management.
  • Coda App: A quality code editor that integrates with SVN
  • TextMate: Another quality code editor with SVN integration
  • MAMP: A personal Mac server with Apache, Mysql and PHP
  • VirtualHostX: A virtual hosting utility that works well with MAMP
  • VirtualBox: A sweet virtualization product to run multiple operating systems
  • Spoon.net: A browser-compatibility testing tool

Those of you who are already familiar with SVN know that there is obviously much more to rave about. This post is intended to be a simplified “business use-case” for Magento SVN usage and explain why it is a Magento best practice. Please chime in in the comments below with other suggestions for everyone to benefit from!

Magento Certification Rant: Part 2

· · 3 Comments

Lee Bolding’s comment in the Magento certification discussion on Linkedin was too spot on to not repost:

…Certification would even the playing field a little – I see large agencies, with big clients and deep pockets, with no technical Magento skills, yet (somehow) they’re Enterprise partners. I see small outfits – just a few guys – with wizard Magento skills, but no exposure to either (Magento) Enterprise or larger clients. The end result is that large enterprise clients lose confidence, believing that the larger, non-skilled agencies are “the best of the best” (they MUST be, they’re partners!) whilst the smaller companies (with the wizards) fight to survive because they’re deemed to be unskilled (otherwise, they’d be partners).

Lee is right. Since I’ve talked with him a few times, I’m hoping that he is grouping Elias under that smaller “wizard” company label. We endeavor to do good work. We build complex extensions for Magento. And, quite frankly, we get hammered as a business on our bottom line. No joke. The thought of leaving Magento all together crosses my mind at least once a week. This consideration is fueled by conversations with agencies who make a killing off of other webwork that is, well, easy when compared to Magento.

Our best client in 2009 was an agency. They love us. They now hate Magento. So they stopped selling ecommerce projects to their clients because it was a pain in their butt. Building “regular” websites was more profitable. This is becoming increasingly common as developers forego the Magento learning curve in favor of easier wins.

Or is it a US thing? Magento isn’t as big here in the states as it is in Europe. A client told me that he estimates that there are maybe half a dozen firms in the US who are highly specialized experts in Magento. I know a Mage firm who bought a skype number for the UK and gets 2-3 calls/day from what seem to be higher end clients in Europe. Our module sales are stronger in France than in our own country, which might not be a bad thing since the dollar’s value seems to be deteriorating. We’re currently considering adding another storefront to our module store that is Europe specific to see what impact it has on sales across the pond.

Right now Magento feels like a mediocre hand in poker. Do you bluff your way through it or fold and cut your loses? Would forking over $5k to Varien to slap a professional partner sticker on the site draw in good clients who value Mage services enough to pay handsomely for them? I like Varien. I’m impressed after my conversations with Tim Schultz. I think Roy Rubin is brilliant. But can they create an ecosystem that provides a return on the investments from developers in the community? Jury is still out.

Magento Certification Rant

· · 1 Comment

A discussion about Magento certification popped up on Linkedin this week. My intended comment quickly evolved into a blog post:

The issue at hand is rooted in supply/demand. There is latent, unmet demand for Magento services. Our firm is not certified (yet). However, last night I went to bed with 0 emails in my inbox. This morning I woke up with 4 new requests for help with Magento projects. This happens to us daily. There are simply not enough hands on deck to meet demand.

Uncovering the Root Issue

For many Magento development firms, services rendered end up as a net loss. Magento is complex and demands a highly specialized skill set. Clients want someone to fix their problems within a predictable timeframe and budget. But the reality is that projects are more involved once you dig in and uncover what is going on in the code or what is really expected from the customer. So the developer either burns hours estimating upfront or tacks on extra hours without compensation to fulfill a fixed commitment that was misestimated. In the end, he could have made more money from estimating software or building WordPress sites for local restaurants and dry-cleaners.

At the positional intersection of both store owner and developer is one thing: risk mitigation. Store owners want to know that their store will get done properly and within budget while developers want to know that they’ll be profitable and appreciated in their work. Both sides are deathly afraid of the opposite experience.

Enter Certification

Magento certification should be aimed squarely at risk mitigation.  Most current programs get off balance by offering some sort of training + certification exam combo to provide enablement. Services are more profitable when associated with a product; and training services wrapped around certification are probably no exception. However, this approach ignores the chief value proposition for the developer, who is ultimately the paying customer. Remember, he simply wants to lower risk by attracting higher quality clients and charging more money for essentially the same services already being offered. He usually doesn’t want more training.

What we need is a streamlined certification exam like Google offers. You charge me $50-$100 and I’ll happily pay to get 3 developers through a certification exam. But anything over $500/certification that also requires me to lose bandwidth while developers sit in training does not currently make business sense. That is, unless so many other developers get certified that I lose out on business or enough upside exists to justify the cost of certification (which I believe might end up becoming the case based on my conversations with Varien/Magento, inc.). But for now supply/demand seems to be in favor of the developer. If only we could all just figure out how to operate profitably.