Tag Archives: Agile

UrbanCode Tradeshow Participation 2013

Posted on by
Reply

It’s going to be a busy year for UrbanCode as we make our way around the globe.  In 2013 we are planning to attend the following tradeshows:

DevOpsDays – London, UK – 3/15 – 3/16

MileHighAgile – Denver, CO – 4/19

CA World – Las Vegas, NV – 4/21 – 4/24

Chef Conference 2013 – San Francisco, CA – 4/24 – 4/26

Code Palousa – Louisville, KY – 4/25

DevOpsDays – Austin, TX – 4/30/13 – 5/1/13

Knowledge13 (ServiceNow) – Las Vegas, NV – 5/12 – 5/16

DevOpsDays – Mountainview, CA – 6/21 – 6/22

TechEd North America – New Orleans, LA – 6/3 – 6/6

GartnerIOM Summit – Orlando, FL – 6/18 – 6/20

CITCON – Boston, MA – 8/23 – 8/24

Agile 2013 – Nashville, TN – 8/5 – 8/9

VMWorld13 – San Francisco, CA – 8/26 – 8/29

GartnerAADI13 - Las Vegas, NV – 12/3 – 12/5

 

Please contact Chad Kurena at cmk@urbancode.com if you would like to join us in your city!

Four signposts towards a DevOps friendly SDLC

Posted on by
Reply

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 →

Continuous Integration: Why You Don’t Really “Get It”

Posted on by
Reply

Vast majority of daily practitioners of Continuous Integration don’t really understand it. This is a bold statement, I know. But it is not made to simply capture attention. Most practitioners of Continuous Integration, when asked, will either tell you that CI is about integrating changes often, or that it’s about producing frequent builds of your software. Both these answers are incomplete at best. Even articles on Continuous Integration gloss over the thinking behind it and jump straight to the implementation.

So this blog entry is about the “thinking” behind Continuous Integration. Because only by understanding the core ideas behind CI can you understand what is happening in the industry now or get a glimpse of where it is headed in the future. Once you “get” the core concepts behind CI, it’s easy to see that Continuous Delivery is a natural extension of Continuous Integration. Continue reading →

DevOps: The Rise of QA?

Posted on by
Reply

The DevOps movement which has been doing hard work to break down silos, improve deployment quality and even push towards continuous production deployments has focused on improved cooperation and communication between developers and the system admins (operations) who deploy releases out into production.

Recently, I’ve been wondering, “Where’s QA and test?” The DevOps community has put a lot of emphasis on automated testing, which is great, but I haven’t heard a whole lot about where manual QA fits in.

Listening to Timothy Fitz from IMVU champion continuous production deployment at the recent Leaders of Agile virtual conference was a little reassuring. Even though IMVU automatically deploys most code changes that pass tests to production – deploying many times a day – there’s still skilled, human testers involved. They test new functionality and features before those features are enabled and made visible to end users. So, QA and testers do have a place.

A aggressive view of the role of testers was presented by Bola Rotibi’s in her editorial in SD Times, “Rise of the machines: Power brokers in DevOps bonding! While Ms. Rotibi’s thesis was that communication and automation are key (and we love that), she explored QA’s role as a conduit and facilitator between development and operations:

The line of communication between Dev and Ops needs to be clarified. Neither is well-versed in communicating what either needs to carry out their respective responsibilities. QA and testing, a group within the software delivery team, could and should help smooth the relations between the two sides.

Today, testing is seen as an extension of development rather than a core part of the deployment team. But QA and testing teams need to have a broader scope and a more active role in shaping and strengthening the DevOps relationship. Many of the management and monitoring tools are raising the profile and capability of the testing function as a key conduit between DevOps.

This strikes me as a critical step in the evolution of a traditional, siloed IT shop into one with stronger development to operations coordination, trust and cooperation. Even today, QA teams have many of the needs of development teams as well as operations. They have infinite work and need to move quickly and test new builds frequently. Their pace is closer to development’s than operations. At the same time, if things aren’t being installed properly in QA, if control is lacking, their work can be wasted. QA should be primed to lead Dev and Ops as they move forward with Agility and Control. What remains to be seen is if QA and test has the courage to embrace automation and enough respect from their partners in the IT organization to be able to lead.

From Agile to Dev Ops

Posted on by
Reply

Steve Berczuk has a nice article up on CM Crossroads, “Agile Teams care about Dev Ops”

Key quote:

… The next logical step is to routinize deployments into production. For this to happen the project team needs to incorporate operation issues into the backlog early, and incorporate operations team roles into the core development team.

Some concrete steps that teams can take to move towards a dev ops perspective are:

  • Including the operations team in the project team. Some tasks might lend themselves to implementation by someone familiar with  the operations systems.
  • Extend your toolset to include tools that the operations team can easily use. Your may be developing a web application in Java, but some deployment and configuration tasks might be easier to execute in, say, Bash of Python.
  • Developing tools and process to do deployments into production early. These tools should be in a form that works well in an operation environment, and be as automated as possible.
  • Making realistic deployment environments available to the team so that production deployments can be exercised early, and automated.
  • Place system artifacts under the same change management paradigm that you use for code. The tools may be different, but the you should strive to deploy not only an identical version of the code, but an identical version of the code in an identical server configuration.

I really couldn’t agree with Steve more on these points or the rest of his article. You really want to push realistic practice deployments as far down towards development as possible, and have solid partnership between developers and operations teams. Throwing things over the wall just doesn’t cut it when you have Agile throwing things over the wall at a faster and faster pace and the cost of failed deployments is high.

 

Agile Developers are a Pain for Downstream Teams

Posted on by
Reply

Test and Release teams need to adapt

Let’s face it, Agile development teams are causing lots of problems. As the developers are going Agile, QA finds the ground shifting beneath their feet. Operations is being asked to deploy more often.Testers are the first to suffer. They are either broken up and added into the scrum team; or asked to work side by side with those lunatic developers; or asked to test different builds every day, or only get a couple days at the end of each sprint to test. Agile teams deliver new, testable builds more quickly than anyone could properly execute tests.

The middleware / operations / deployment guys are right behind though. First, the QA team is getting all those drops from the developers and needs some help getting them all installed. The developers are also shooting for more, smaller releases to production as well. Existing processes for handling a couple of production deployments a year, just don’t cut it.  Continue reading →