Continuous Testing

Subscribe to Continuous Testing: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Testing: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Continuous Testing Authors: Wesley Coelho, Rainer Ersch, Stackify Blog, Plutora Blog, Liz McMillan

Related Topics: Cloud Computing, Continuous Integration, DevOps for Business Application Services, Continuous Testing, DevOps Journal

Blog Post

IT As Competitive Differentiator By @Automic | @DevOpsSummit [#DevOps]

You need to get to a stage where Dev and Ops are not only working together and understanding what each other are doing

Making the IT Department a Competitive Differentiator: Getting Started

By Benedikt Eckhard

The best piece of advice I ever got about improving workplace productivity was from an enterprise CIO who'd managed complex IT environments for some of the world's largest companies. He said to me: "Get the IT organization right, and the rest of the organization will take care of itself."

Today everyone is looking for productivity advice and quick fixes - to the extent that the IT infrastructure gets neglected. Call me old fashioned, but soft cultural stuff is not going to fix underlying problems with your IT infrastructure.

You need to get to a stage where Dev and Ops are not only working together and understanding what each other are doing, but where IT is a real driver of business performance. Getting to that stage is going to require some heavy lifting in the background, but get it right and you'll be primed for the likes of 3x or 4x growth, rather than settling for incremental improvements.

So how do you get there? For me, that's about getting serious on continuous delivery and really investing in IT as a key differentiator rather than a "keeping the lights on" operator.

Every CIO feels like they are in a Vipers Den from time to time, and when you're in that place, it's hard to imagine jumping from IT complexity to a world of continuous delivery and DevOps. But it can be done. Here are some lessons learned that can help you along the way.

Before you start:

Break out of the Waterfall mindset

The way software and application development was done in the past bears very little relation to how it should be done today. In the past, software was "broken" for much of the release cycle, and then "fixed" for a master release.

The easiest way to organize software releases in the past was to build iteratively towards a "master" release frequently rolled out once a year or every six months if a company was ambitious. Today if you waited that long, your competitors or a new start-up would outpace you and your customers would abandon you.

The way around this is releasing updates frequently through continuous delivery. The fact that continuous delivery makes it cheaper and lower-risk to release new versions of your software might not be much of a reason to do it (although that's certainly a nice by-product). What you're actually getting is the ability to provide value to your customers much quicker and react to their feedback.

I think a quote From the Agile Manifesto sums it up best:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Break code into smaller chunks

When I'm running an IT project, I almost always look for the smallest possible unit that can be shipped. It has almost become instinctive.  Your number one priority as a developer is to push code to production. Big impressive feature lists should be secondary.

Why should I look for the smallest deployable unit you may ask? Well, because it enables you to focus on your two most important tasks:

1) What does the customer need?

2) What do we need to build?

Software development should be a journey of constant discovery - you shouldn't be trying to second-guess what the customer wants. Instead, you should be trying to figure out how you can meet that need and profit from it.

Implement automated testing...yesterday

Automated acceptance testing is really, really important, even though we know it is a hassle to set up. Every time I've skipped through it, I've ended up regretting it big time. Automated tests are your safety net - they are not there to ensure that your software works, but that it still works when you add new stuff. It is imperative to make sure that automated acceptance tests are written at the same time you are writing new code. Believe me, you don't want to go through the quagmire of manual regression testing.

For inspiration, take a look at companies that are already practicing automated acceptance testing. I would encourage you to use online guides from the likes of Mozilla (https://developer.mozilla.org/en-US/docs/Mozilla/QA/Automated_testing) to Dorothy Graham's book on Test Automation. It will help give you ideas on how you can apply automated testing in your organization and an understanding of how it is already benefitting others.

By being aware of how automated testing has worked for others, you can avoid some of the pitfalls before they occur. It's seriously worth it; no one ever got fired for testing too much.

Put version control in place

It's 2014 and we seriously should not need to talk about it: If you're going to be a high performing IT organization, you need version control. Version control gives you the ability to rollback changes to code, avoid the problem of old backups, maintain multiple instances of a product, review the history of code and much more.

If you've ever had to comment out code, you'll find version control a breath of fresh air. Old code doesn't clutter your screen, and it's not lost. It can be recovered easily by checking out an old commit.

Don't try to wing it. You need to be able to check everything it takes to reproduce your production environment into version control - and that's your productions environment infrastructure setup itself.

Why this matters...

Of course, none of this is easy. People always ask me whether peer-reviewed change approval is really an improvement on the standard change approval board process, or whether full version control is necessary for IT Performance. Why spend so much time getting the fine details right?

Because time and time again, those details are the differences between success and failure in an IT organization. These techniques, taken together, are the techniques that really turn IT into a competitive differentiator. It's how you leapfrog the competition instead of getting caught up in feature / function battles.

All of this takes time and resources. But how expensive is going back and doing it again? How expensive is a botched deploy? How costly to the business is being unable to tackle a new market because you can't satisfy regulators?

Making IT Performance a competitive differentiator isn't an option, it's the only option.

Read the original blog entry...

More Stories By Automic Blog

Automic, a leader in business automation, helps enterprises drive competitive advantage by automating their IT factory - from on-premise to the Cloud, Big Data and the Internet of Things.

With offices across North America, Europe and Asia-Pacific, Automic powers over 2,600 customers including Bosch, PSA, BT, Carphone Warehouse, Deutsche Post, Societe Generale, TUI and Swisscom. The company is privately held by EQT. More information can be found at www.automic.com.