Happy New Year! I hope everyone had a joyful and triumphant holiday season. Only 4 short weeks remain before it is no longer socially acceptable to keep those Christmas lights shining brightly in the front yard. Fight the power!

In today’s blog I wanted to start off a new series that focused on how we actually develop software here at CA. I’m not referring to specific algorithms or architectures, but rather the overall Software Development Lifecycle.

Why on earth would you care about that? Well, if you ever had a bug you wanted fixed (and of course our software has no bugs, right?) or a feature you wanted added to the product, it’s empowering to know how we approach software development to better understand what and when changes can be delivered. This is a big topic with lots of facets to cover, so I’m going to split this into 3 parts. Think of it as a trilogy if you will. Hopefully you’ll find the plot to be interesting and the acting better than that of Hayden Christensen.   Evil Anakin
I’m good…no wait I’m evil!

Software as a Service
Although this is likely blatantly obvious to many, it’s worth reviewing as it’s critical to understanding our development process: all ChannelAdvisor products, including Pro, Merchant, Search, Shopping, and more, are what the industry calls Software as a Service (SaaS) solutions. SaaS products are typically web based and are expected to be available 24 hours a day, 7 days a week, 365 days a year (we take leap day off, j/k), with some small exceptions for occasional early morning maintenance windows. SaaS solutions have tremendous advantages to our customers: all you need is a web browser to use our tools anywhere in the world, any time of day or night. No need to install from a CD or get the latest patch, you’re always guaranteed to be on the latest and greatest version with no effort on your side required. If there’s a bug that needs to be fixed or a new feature people are screaming for, we just push out that change to our production server environment and (Bam!) everyone gets the change. This is good stuff.

Of course it’s not all peaches and cream as the reverse is also true: if there’s a bug in our software and we deploy it to the production environment, (Poof) everyone sees the bug instantly. If one of the servers dies or the Internet connection is severed, suddenly productivity grinds to a halt. This is the tradeoff the modern business world is learning to accept as the pros usually outweigh the cons, as long as the duration and impact of problems can be minimized or eliminated. This is what is commonly referred to as the “reliability” (likelihood of being bug free) and “availability” (likelihood of being online and accessible) of a system. I talked about this a lot in a prior posting so won’t belabor that here.

Environments
When you fire up a web browser and point it at http://pro.channeladvisor.com, http://merchant.channeladvisor.com, http://searchtraq.channeladvisor.com, etc. your request is actually routing to a server in what we call our “Production” environment. There are many servers networked together in that environment (another prior blog talked more to that) which have the latest and greatest code level running on them in concert. This constitutes what you see as the “ChannelAdvisor Software”.

What you don’t see, however, is that we also have scaled down “copies” of those environments to develop and test our software before it reaches your eyes. As good as our developers are, they still need a place to try out the new software and fix any defects before it goes “live” to our production environment and your web browser.

Specifically our environments break into the following categories:

  • Development: This is where the code is written and tested by the developers. If there was a garage with an engine pulled out of a car, this is where it would be.
  • QA: At regular pre-arranged “milestones”, the latest version of the new software is delivered to this environment for our Quality Assurance team to perform functional testing (making sure the new features work as designed) and system testing (making sure the new features play well with other existing features). The engine would be back in the hood here, but the driver door may be off so you can shine a flashlight on the break pedal.
  • Staging: Just prior to launching the software, the code is delivered to the staging environment for final regression testing. Our staging environment is designed to be as close of a copy of Production as is feasible by the budget. Regression testing validates that (A) we didn’t break anything that used to work and (B) our process of pushing the software to the new environment did not cause any new problems. To continue the analogy, the car is all assembled and driving around the test track here.
  • Production: As discussed before, this is the “live” environment that you use day in and day out. This is where the latest code runs on the best hardware and is monitored the closest. (Which reminds me, discussing our monitoring processes may be a good topic for a future blog. Lots of good info to discuss there, stay tuned…). Here the car is screeching tires on the way out of the dealer’s lot…



    • So the lifecycle of our software typically flows from Development to QA to Staging to Production. To further complicate matters, we also have the concept of “Short Term” changes and “Long Term” changes, each with their corresponding versions of the “Development” and “QA” environments (e.g. “Long Term Development”, “Short Term Development”, “Long Term QA”, “Short Term QA”). I’ll get more into that in my next posting.

    In the Next Episode
    So now that you better understand the nature of our software and the environments it lives in, I’ll launch into the mechanics of how we deliver that software in my next 2 postings. Specifically, I’ll be looking to cover the following topics:

  • The difference between “Defect”, “Enhancement”, and “Workorder” and how each are filtered into our system and prioritized.
  • Our “CRT” Process for delivering defect fixes, enhancements, and workorders in a structured, quality-assured manner on a rapid and responsive schedule (typically twice a month).
  • Our “Hot Fix” process for urgent, same-day response to critical, high severity defects.
  • Our “Long Term” process used for delivering large scale enhancements like Matrix Inventory and Stores Search.
  • Our adoption of agile software development methodologies, including Scrum

    • If I missed anything or you’re particularly interested in some specific areas, feel free to post some feedback and I’ll endeavor to address those questions as best I can.

    See you next time!

    Share This