uChat 3 : Continuous Integration

UrbanCode CEO and co-founder, Maciej Zawadzki, explains that Continuous Integration is more than just merging code. Join him as he explains some of the fundamentals of Continuous Integration in the third installment of the uChat video series.

For more information on CI, CD and DevOps, watch “Continuous Integration, Continuous Delivery, DevOps and What They Mean to You,” hosted by Maciej Zawadzki and Eric Minick.  This 60 minute webinar discusses the progression of Continuous Integration, the current state of our industry, and the future that is DevOps.

DevOps Skills in Demand

Companies may not know exactly what DevOps is yet, but they know they want people with “DevOps” on their resumes. For the last few months, I noted the steady flow of “Wanted: DevOps Engineer” postings floating past on the forums I frequent. While in past presentations I’ve fought the idea that DevOps is a job title, I’m nearly ready to concede defeat.

The trend is definitely towards hiring people for jobs that require DevOps skills or titles. PC World reports on this trend with a look at what’s going on at the popular techie job site Dice. Over 200 listings per day show up with a mention of DevOps. Filling these positions is hard, and those with the skills are getting paid better and better. And while classic Web 2.0 players, and e-commerce players like Amazon and Ebay are present, you see more mainstream companies looking for these skills as well (NPR, Travelers Insurance, etc).

I think that for job seekers, this trend is one to take advantage of. If you were providing build, deployment, or release infrastructure and regularly interfaced with both App-Dev  and operations teams, your resume should say, “Worked on a DevOps team that…”. You should do so because its true. We finally have a term for people who grok both sides of the house. Embrace it and run with it.

For everyone else, I think this is a pretty clear signal. It’s time to embrace your counter-parts on the other side of the wall and start working together more and more. This isn’t a fad. It’s the mindset IT shops are re-organizing themselves around.

You should also checkout our recorded webinar: DevOps - IT's Automation Revolution featuring Glenn O'Donell of Forrester Research, Inc.

Putting the Dev in DevOps

I recently attended devopsdays Rome.  This was my first time at a devopsdays conference and I enjoyed the mix of talks and open spaces sessions.  It was obvious that the presenters and the attendees have felt the pain of trying to introduce continuous delivery in their organizations and were there to share stories and seek advice to help.

The theme for this conference was “Culture”.  If DevOps is a “culture thing”, then surely we need to involve both Dev and Ops.  The surprising part was that there did not seem to be anyone from the Dev side of things.  In fact, there were topics like “getting Dev to think in terms of DevOps”.  The goal being to entice developers to think about the infrastructure of their applications including the operational concerns such as: scalability, redundancy, performance, monitoring, and feedback.

Monitoring was a very big topic, being covered by some 70% of the talks.  For this crowd, Puppet, Chef, and CFEngine define configuration management.  But it stopped there. Adding all of the discussions about stacks, tools, and cloud together yields something that looks like PaaS.  It allows them to provision and configure machines or virtual machines to provide well-managed and monitored services on which applications can sit.  However, at that point, Dev has no skin in the game.

Application delivery is needed to get Dev thinking in terms of DevOps.  Specifically, if while developing application components, developers need to concern themselves with how their components will be deployed to an environment and in a state where they can deliver value.

uDeploy deploys complex, multi-component applications.  For example, a simple web site consists of a web component (WAR file) and a database component (DDL).   Continue reading

Four signposts towards a DevOps friendly SDLC

In last week’s “DevOps Imperative” webcast, I mentioned that DevOps is more directional than prescriptive. I mentioned that the key directions to follow were to push towards more collaboration and automation to enable your team to deliver more frequently with less risk.

Four of the principals and laws we cite most frequently in white papers and webcasts can help reinforce this direction and provide some needed checks as you begin transforming towards an organization whose path from idea to value (the software development lifecycle or SDLC in stodgy terms) needs to be more DevOps friendly.

Conway’s Law

What it is: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”

Why you should care: Conway’s law points out that when we design some solution, and we put three teams on the project, the solution will likely have three sub-systems and the Continue reading

3 Crazy ideas to make your DevOps proposal seem reasonable

I work with “The Enterprise” everyday. Sadly, this has nothing to do with Star Trek – just big companies with lots of internal politics. As our friends champion our products internally,the political challenges are often tougher than the technical ones.

If politics is going to be a barrier, it’s fair game to use political theory to fight back.

The Overton Window

The Overton Window is a concept that has been gaining traction over the past few years. The idea is that people are scared of extreme ideas, and prefer moderate ideas. To push an idea towards the idea of acceptability one can work hard to persuade the group that it is reasonable. Alternatively, an ally propose a new and more radical idea that makes your idea seem reasonable by comparison.

A new crazy idea makes a desired idea more attractive.

A new idea fills the window of what the public regards as unthinkable, causing the desired idea to shift into the window of what the public views as sensible, without its proponents necessarily having explained any benefits of the desired idea. *

 

Continue reading

The DevOps Scam?

Ted Dziuba has a great blog entry: “DevOps is a Poorly Executed Scam. The post has been around a while, but I just noticed it and wanted to comment. ” The ” scam ” he points out is that unlike Agile, nobody has put out the book, performed and (as the author of that book or common speaker on the circuit) cashed in with massive consulting rates. I’m sure someone is hard at work in doing that. Ted highlights the folks behind XP and Scrum as executing the “Agile” scam well.

Setting aside the inflammatory nature of the word scam, there’s an important truth. With any of these movements / philosophies the enterprise is going to be hard pressed to take them on, unless someone writes up a practice. DevOps has no XP and certainly no Scrum. Scrum for all its warts, and horrible implementations at some companies, has done great things by making Agile palatable to the enterprise. The “cool kids” in the industry look at CSM as an obvious scam, but certification makes the enterprise comfortable. The executive thinks, “If I can’t get a certified Agile guy, then it must not be grown up enough for my company.” Continue reading