A DevOps Vision with GitHub, Artifactory, Bamboo, Arquillian, Selenium and LiveRebel
“Mastering Release Management using tools like GitHub, Artifactory, Bamboo, Selenium, Arquillian and LiveRebel ensure an automated deployment pipeline that can bring your organization into the mental area of DevOps and on the road to seamless Continuous Delivery.”
Part I: DevOps improves Release Management and Deployment Automation
It’s time to recognize that DevOps as an IT philosophy cannot be ignored, and is already embraced by companies like Netflix, Etsy, Twitter and others. Are you preparing for the next wave of predictable, automated releases to become the standard for your users?
DevOps in a Nutshell
You’ve probably heard of DevOps by now. For an individual, DevOps is a state of mind. It requires discipline, a sense of mutual respect between individuals, teams and even departments, focus on the big picture, and a strong commitment towards delivering on business goals. It thrives in a culture where development and operations teams unite, to draw from each other’s experiences, perspectives, concerns, and continuously improve processes to build and deliver resilient products rapidly, into the hands of delighted customers.
DevOps is not noOps, nor is Dev in Ops clothing or vice versa. It is synergistic rather than cannibalistic. Opscode, makers of the handy virtualization tool Chef, say that DevOps is about CAMS: Culture. Automation. Measurement. Sharing.
Developers and operations folk bring a unique set of skills and experiences that the team draws from, to develop and deliver awesome software applications!
The DevOps Dichotomy
Now that we’ve broadly defined DevOps, let’s apply it within the constraints of the real world.
Once upon a time, things got complicated …
Complexity drives specialization. So naturally, as software, systems and infrastructure have grown increasingly complex, so has a need for specialization. It’s unrealistic to have any one person be an expert in application design and development, infrastructure and network configuration, and everything else that comes with the game. This drives specialization. So when you build a team, you bring in specialists that have a deep knowledge in the required areas. Then you have them work together to design, develop and deliver the best possible manifestation of an idea as a product.
People adapted and did the best they could …
Let’s face it – as humans we often love to be the best at what we do, and stand tall amongst our peers. Just like how you want to be the best network engineer who can configure HTTP headers while blindfolded and typing with one finger.
To get stuff done by (barely) working together …
This combination of needs for specialized skills and human motivation, encouraged by growth, further drives team fragmentation. Before you know it, the devs hang out together talking about new libraries and SDKs. The Ops folk talk about setting up cloud redundancies, the network guys talk about subnetting and VPNs and so on. Basically, each group cares about its core areas and has little communication with the other groups. But they are still required to accomplish a singular business goal as a collective.
And they lived (happily) ever after…right?