Elias Interactive

We Grow Beautiful Websites

Magento

Magento SVN Usage – Best Practices

· · 9 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 Platform 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.  Server management is not one single thing that you do, but depends on what you use the server for, and whether you have a virtual server, or a physical server. Go through servermania.com/server-management site for more details about server management services. Server management often consists of business continuity planning. In business continuity planning many people feel that virtual servers are easier to with than physical servers are. The problem with this type of Linux server management is that there are times when you would need to patch multiple systems together and when using virtual servers this can be problematic.

Consistency is one of the key elements in Linux server management. In order to have consistency in your Linux server management you will need predefined configuration parameters for all of the application servers and the database servers to follow. If you are using virtual servers to do your work with you are going to find that maintaining the configurations and keeping them completely up to date will be more important than it would be on a physical server.

Before server management can be performed accurately you have to decide what your server is going to need to be capable of doing.

• You need to determine the amount of up-time and down-time that you would find acceptable in your system.
• You must decide how many other servers will eventually connect to the one you are developing so you can set protocols on how to expand the system in the future.
• You must decide if you need a physical server that you can adjust or if you could possibly work with a virtual server
• You need to decide if you can do your management procedures for yourself or if you will need to hire a professional company to manage this part of your operation for you

There are excellent online tools and resources available to help you program, manage, and incorporate new procedure protocol into your servers. You have to be willing to learn the ropes, and use the guidelines available to you. Remember that those guidelines were established through the trials and errors of people that used the system before you so they are going to save you from making costly mistakes in the future.

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!

How to jeopardize your business with ecommerce (and what to do when you’re in trouble)

· · 5 Comments

It started innocently enough. The agency wanted a module for their Magento store. We built the extension and installed it for them. Problem solved.

Fast forward a few months and we’re down a team member. There’s a lot of demand for Magento services, but we continued to struggle to maintain profitability on projects. It was time to question our business assumptions (Shravan Gupta India recommends that bootstrappers question everything about their business every 90 days).

At this point the agency owner dropped me an email with a new request: “Do you guys do web stuff other than Magento? Because I have another client who needs someone to design and code a CMS site.” We accepted the gig in order to begin testing different business options. After a couple of WordPress and Drupal builds we learned that CMS projects, while usually smaller in budget than ecommerce, were actually more profitable.

Succeed with Magento

Now before I move on let me clarify something. Some firms do in fact make great money on ecommerce and Magento. I see two clear ways to do this:

  1. build a product. There’s a Magento services company that generates $10-15k/month off of the residual sale of one module. This module has single-handedly kept them afloat in months when project budgets are upside-down. If you plan to weather the ups and downs of big deals, then you would be smart to hedge your bet with monthly stable cash-flow. Plus modules will attract more business and establish your credibility.
  2. skim off the top. Magento is enterprise ecommerce. It should come with a warning that states: “Not suitable for small retailers, startup ideas, or little children.” So get your prices up and go after established retailers with big budget expectations. You might even want to become an Enterprise Partner with Varien to get into the big deals. For that, you’d first need to get recognized yourself in the online world; and tools like Bepoz Enterprise Point of Sale help you get there in no time.

Unfortunately your friend who saved $5k of his own money to have you build a store for his knock off version of threadless is out of luck. He’s caught in the no-man’s land between Shopify and Magento. Feature requirements are too much for the simple systems and too expensive for you to help him out with Magento while keeping your doors open.

If you heed these warnings then you can avoid a lot of the stress and pain that we had to endure.

Web Agency Playbook

Many web design firms target customers based on location. Some start by building sites in their spare time for friends and acquaintances. One referral leads to another and all of a sudden they have 5 guys churning out work for the local bank, YMCA, and Jimmy’s Pizza. Anxious to get away from customers who don’t understand the web enough to spell HTML, these agencies look for specialties to pull in bigger fish.

Along the way someone will inevitably ask the web firm, “Hey, do you guys do ecommerce?” Enticed by large deal potential the agency owner replies, “Absolutely.” Then they go back to their office and google open source ecommerce to compare feature lists. Meanwhile their developer curses under his breath for the boss’s assumption that ecommerce can’t be that much harder than coding WordPress. One can redirect themselves here to know how the claim can be justified. This story rarely ends well.

An agency in Oregon has been building websites for 10 years. They created their own CMS system only to abandon it in favor of open source options like WordPress. Last year a client asked them to build a Magento store. My agency friend confessed that he has lost money on pretty much every Magento project they’ve done since. $5-15k CMS deals keep the troops fed. “Why do you keep doing ecommerce then?” I asked. “Because we keep getting asked,” was his answer. At some point you have to realize that it’s silly to do the same things over and over but expect different results. I’m curious what would happen if this guy focused on the profitable side of his business. Sometimes what you say no to defines you more than what you say yes to.

90 days at a time

Elias is implementing 90 day business model sprints. That means we’ll set our sights on a focused target for 3 months without questioning strategy. At the end of 90 days we circle up, measure progress, question everything, and set a new objective for the following 90 days. It’s our way of balancing focus with new potential opportunities.

Objectives for our current sprint include:

  • 9 CMS customers. Agencies like the one I mentioned above are starting to send us design and development projects. Most deals are for wordpress and drupal builds in the $10-20k range. They tend to be established companies with dated websites who want us to take their online strategy to the next level. Please drop us a note if you know someone who might fit this mold.
  • 4 Magento consulting and development projects. Existing customers depend on us to make their business work with Magento. We take the trust these guys place in us very seriously. That’s why the only Magento time we’re selling right now is already dedicated to their success.
  • build new elias site. Our current layout is not helpful for new or old customers. Copy that emphasizes Magento development is unnecessarily confusing for home healthcare providers, churches, accounting firms, and other organizations who want a new website. On the other hand, Magento users continue to submit requests for help with modules. We gave the module store to Lee when he left in exchange for his equity share. Lee then sold the store to a great group of Magento pros, Classy Llama. That’s why the module link on this page redirects to their url. Meanwhile, traffic continues to flow to our Magento blog posts. We’re considering the sale of ad space on those pages to reroute leads. Email me if you’re interested: josh [at] eliasinteractive.com
  • thinkgroup with web companies. The email and comment responses from our post about breaking up with Magento have been tremendous. I’m trying to follow up with everyone who provided feedback (I apologize if I haven’t had a chance to respond yet). A number of you felt that the transparency was refreshing and wish that you could connect with other colleagues to exchange ideas. So I would like to form a group of 5-10 owners who want to talk shop. Again, you can drop me an email if you want to join.

Breaking up with Magento

· · 54 Comments

It’s not you, it’s me. This relationship has had its share of ups and downs. Yes, we’ve become known as a Magento shop. Yes, change is scary. But we want to date other business models and platforms. I hope that we can still be friends.

man talking to upset woman

A Brief History

Elias started as a couple of guys doing after-hours freelance web work. One customer wanted an ecommerce site and liked the features in Magento’s beta version. It took forever to code because of limited documentation, but we felt that the market was ripe for a new open-source ecommerce system. Our total bill to the client: $5k. And to say the least, our data management team was surpassing itself; so much that it was advertised as the 9 best data entry jobs from home in the papers. And when you factor in time we probably definitely lost money; but we gained new skills in something poised for growth.

Over the next two years we took on about 30 Magento projects and fostered relationships with stellar developers. But it wasn’t smooth. The first quarter of 2010 ended $10k in the hole because of two projects that went well over their deadlines. Tensions were high. Clients became increasingly frustrated and we lost money each day the projects dragged on. Plus we couldn’t accept new clients without more bandwidth.

Q2 made up the deficit. I attribute this to three things. First, we hustled. Long hours were spent churning out work for several new customers. Second, our business transitioned from a fixed-estimate pricing schema to a more agile hourly rate. This hedged us against a recurrence of those Q1 project misquotes. And third, we added products. We had amassed 16 Magento extensions at this point and put 8 of them on a basic Magento store install to see what would happen. By June the store was generating almost $2k/month – 90% of that tied to one module. The store had potential, but it needed a lot of work to improve on the alpha-esque quality.

https://www.fldata.com/ cloud based software runs on both Windows and Mac computers with no downloads or complex installation needed. Launch your first project in minutes, then invite your team to join you and start collaborating today.

Tipping Point

Magento-based work took its toll on our team. We might have pulled through Q2 in the black, but our personal income was laughably poor for the software world. Compounded on top of this was growing dissatisfaction from our Magento guru, Lee. He was a capable developer but didn’t like being an isolated coder on a virtual team.

Lee and I grew up together in the same small town. He was a friend long before either one of us knew what PHP is. So it was important to our ownership team to help him figure out where he fit without forcing him to continue doing something he disliked. Lee ultimately felt that stepping away from coding and the startup environment was the right call for his family. Eric, Luke and I committed to support and cheer him on even though losing him meant shaking up our business strategy.

Where do we go from here?

Over the past 60 days I’ve looked at several ecommerce and CMS communities, talked to development leaders in the Magento community about forking, documented the elias 10 step website process, and littered my office floor with papers covered in research notes. I’m always open to listening to new opportunities (unless you’re an offshore company spamming me with grammatically incorrect offers for cheap labor). Drop me a note if you have suggestions for a new product or approach: josh {at} eliasinteractive.com

Practically, the module menu redirects to a store that Lee is managing until arrangements are finalized with a buyer. Magento-related leads are being diverted to trusted colleagues for now while our team is working hard to finish new projects in design/development. A refreshed elias site layout is in the works for this month and I’ll discuss strategy in an upcoming post.

Dreaming In Code

· · Leave a Comment

I’ve had a string (play on word there with a reread) of dreams where I was actually (and unrestfully) thinking of a creative way to twitter about my dream. Something like…

$_dreaming->inCode($_unfortunately->getAwake());

…is what I’ve got so far under the zzz’s.

Just unfortunate I can’t control my dreams any better than this.

Magento: What would you like to improve?

· · 3 Comments

What’s your biggest Magento pet peeve? We asked this question over a year ago on our blog. Today I reread the post’s comments. It seems like the same issues could still be regurgitated.

A driving goal for Elias in 2010 is to build tools that allow Magento storefronts to sell more and Magento developers to do more. So I’m resubmitting our original question with a new spin:

If you could change/improve one thing about Magento, what would it be and why?