Go Lean: SysOps, DevOps, AppOps, NoOps

I’ve always been a big fan of tools and services that take complexity away from engineering teams and allow them to be lean and focus on what they do best: building their product and focusing on their own rocket science.

Back when I started to work with the Web, I remember us ordering an actual physical server, setting it up and loading it into our car to carry it to the data center. Fast forward a few years and you can do all of this within a few minutes without moving away from your desk. Especially working with infrastructure has changed a lot since AWS, Heroku, AppEngine, Parse and all the others appeared.

In one of my previous startups we thought “DevOps” would be the way to go, bridging the (cultural, among others) gap between developers and system administrators. Back then built it around AWS which still required work and expertise around the infrastructure.

Again fast forwarding a bit, this has even become simpler. Especially for early stage startups, where agility and the ability to move fast with limited resources and a laser-thin focus is more important than building proper scalable software, you can build stacks on tools that do virtually everything for you. Deploy your stuff to Heroku (or EngineYard, or …), make it “Continuous” with Codeship, CDN-ify it with Cloudflare, get your basic reporting done with Chartio, and so on. By building such a stack of tools you can nearly entirely avoid having to deal with the adminstration overhead you used to have when building software. In this post, Adron Hall of New Relic (who arguably knows a lot more about it than I do) talks about it calls it “AppOps” and “NoOps”. The former basically let’s you do your Ops work with applications that sit on top of your infrastructure and hide the nastiness, where the latter eliminates it almost completely.

There will be a time where you have to migrate away from these out-of-the-box tool stacks, be it for scalability reasons, or functionality, or cost, or other factors. But if you just need to get started and move fast early on, having “No Ops” sounds wonderful to me and the possibilities and tools are just getting better every day.

The Web / Mobile Feedback Loop

Backlogs for Web and mobile products don’t exclusively contain new features. One eye should always be on what has been done and how that is working out. A proper feedback loop gives valuable input that helps to determine what should be done next.

On one hand, of course, there’s high level goals and vision that define new features and the larger chunks of upcoming work (which just reminds me of this great article about how Spotify has done Prioritization in their early days). But then there’s more. For example. there’s bugs, there’s A/B testing results, there’s the Google Analytics account that somebody should actually have a look at, and there’s more. Most people know most of these, but mostly, they aren’t managed really well all together. So I thought a good start would be to all those sources of input on the feedback loop that may (or may not) affect our priorities:

  1. The product vision (this is what your management and product managers want to do, the longer term goals, this isn’t actually on the feedback loop, I just wanted to have it on the list)
  2. Business figures (e.g. your sales numbers; I dare say this input is usually indistinguishable from #1 (because it comes from the same people?), but I’d argue that it’s “feedback”, unlike #1)
  3. Analytics (the likes of Google Analytics)
  4. Feedback that is built into your product (without being explicit feedback, it’s basically extracted from normal usage of the app)
  5. A/B Testing (e.g. Optimizely or a variety of other ways to do them)
  6. Explicit customer feedback (lots of sources here incl. all the feedback your customer support and sales teams gather, but there’s also tools you can use that allow your customers to give feedback online, e.g. murm.io (for specific feedback on your existing features) or tools a la Uservoice and ZenDesk)
  7. Crash reporting tools (Crashlytics, Crittercism, …)
  8. Dogfooding (your own company using your product, often this is a much smaller feedback loop since it allows you to get feedback on unfinished work that wasn’t even released yet)
  9. External ratings (e.g. what your users say about your app on Google Play and iTunes)
  10. Customer opinions out on the web (blogs, social media, very similar to the point before but wide-spread on the Internet)
  11. Beta testers and special user groups (there’s a bunch of tools that help you, e.g. Testflight)

This was just a first shot and I’m merely thinking out loud.

It’d also be interesting to see how all of these can be managed more effectively than having different people “keep an eye on it” or having 13 different tools at our disposal to log in and check regularly. I’d greatly welcome less overhead to collect them, a better way to manage and follow up and make them a part of the development process, and create a lot more transparency for teams and stakeholders around them.

I’d be interested to hear what others think or whether there’s anything missing on the list above.

Rails Continuous Integration in the Cloud with CircleCI

Every once in a while I come across tools and services that convince me right from the start. The last one was Nitrous.io, for example. This time it’s CircleCI.

Here at SQUAR we’re doing all our server-side development with Rails. Rails itself does a great job making test-driven development actually work, but without continuous integration (CI), test automation is half the fun (and even less the value, for what’s worth).

I’ve been a big fan of Jenkins since forever and it never occurred to me that I might some day abandon it. Here’s how CircleCI made me do it anyways:

  • Go to circleci.com, sign up with GitHub and a few clicks later your project is all set up and gets CI’ed already
  • CircleCI practically figures out how to build and test our project on its own, so from this point onwards every push to GitHub (master or branch) is being tested. And I receive an email if my tests didn’t run through.
  • It integrates nicely not only with, but also on GitHub. For example it tells me on the pull requests page if my tests for this branch passed or failed.
  • CircleCI infers permissions and collaborators from GitHub, so there’s no accounts and permissions to set up on CircleCI. None at all.
  • It has a hook built in already that can pick up artifacts from a special folder and publish in on the Web on every build page. That makes it a breeze to e.g. integrate test coverage reports by just dropping the HTML-rendered results into this folder and letting CircleCI do the rest.
  • Another good one that I haven’t gotten around to set up yet is the Heroku integration. Setting up a continuous deployment chain that pushes changes from particular branches to Heroku after tests passed is reduced to very few convenient steps.

With Jenkins this would have been quite a bit more of a hazzle to set up. Not to mention that CircleCI is running on the Web and is completely on demand (where are you with that, Jenkins?), with plans that will get you relatively far starting as low as 19 USD/month.

Ok, the above was the short and over-excited run-down of my first experience. I actually need to make a few more remarks to put it into the right perspective:

  • It wasn’t working as out-of-the-box as I described above. I had to make one customization to our build to make it actually work. But this change was well documented and all I needed to do is drop a circle.yml file into my repository with a few lines of code.
  • I also had to jump through a few hoops to make CircleCI pick up our coverage reports. But the support was super helpful and I was actually happy to experience the great customer service instead of being upset it didn’t work right away.
  • We’re only using it for Rails at the moment and it’s great at that. Given that we’re doing quite a bit more (e.g. Android and iOS apps), we’ll have to figure out how much of that we can set up with CircleCI as well. I have a feeling we’ll still end up using Jenkins for whatever jobs CircleCI can’t get done. Because no matter what I said about Jenkins above, it’s still by far the most versatile of ‘em all.
  • There’s also Travis. It’s very established for CI’ing open-source projects and has recently started to become available for private repositories as well. From all I know it’s actually better and more mature and even offers CI for iOS apps (which is rare and awesome). But it does set you back a whopping 129 USD/month for the cheapest plan. I don’t doubt that’s money well invested once you’re at a certain scale, but it felt a bit too much for us as startup that’s hardly 3 months old. Other than that, I believe Travis would have impressed me as an old Jenkins veteran just as much…

If you’re building your tool stack in the cloud then you should give CircleCI a try. And I believe you’ll be stunned, and thankful, and you never want to go back.

Coding Rails apps in the cloud with Nitrous.io in less than 5 minutes

After my friend Minh from TechInAsia told me about Nitrous.io and their 1 million dollar seed funding around a month ago, I’ve been early waiting to get access and try it out. One of the promises was to get working development stacks running in a heartbeat. Today I finally got to try it and I have to say I was impressed.

Timer started, here’s what I did:

  1. I opened www.nitrous.io and signed up for an account. That was basically instant.
  2. Clicked on “New Box”, chose the platform (right now they offer Rails, Node.js, Django and Go), gave it a name, selected a region and clicked on “Create Box”. Provisioning and starting up the box took around a minute. It opened with a window in the browser that contained a file explorer on the left, a text editor in the middle, and a console in the bottom.
  3. A “git clone” in the console pulled in the sources from GitHub in a few seconds.
  4. A “bundle install” pulled in all the dependencies, this took around a minute.
  5. A “rake db:migrate” set up the local database.
  6. “Rails s” started the local server.
  7. And finally, a click on the “Preview Port 3000″ menu item opened a new tab in my browser, pointing to the right URL show my existing Rails app.

All this took less than 5 minutes and I was ready to go. A few further edits, running rails commands, migrating databases again, previewing changes, all that worked like a charm. And signing out on one computer and quickly signing in on the other preserved all the local changes and I could continue immediately.

Again, I’m impressed.