Stream Step

Post it Notes = Agile

Many of us with experience on agile development teams have used "post-it notes" and "card walls" to manage requirements and development work. These tools work well for teams that are collocated and relatively small. But as agile methodologies have matured, teams have gotten larger and more distributed. The market has responded with great tools like Rally (http://www.rallydev.com). Now we can collaborate on agile development processes without needing to be in the same physical room - reviewing the same physical cards on the wall. And of course, now that these agile processes are embodied in software we are seeing value beyond managing the cards themselves.

Spreadsheets = Deployment Coordination

In a similar way - today's deployment processes are primarily coordinated with spreadsheets and conference calls. These tools have worked well - but they are starting to show signs of strain as the rate of deployments increases. (This is especially true in organizations that are adopting Agile development methodologies.) There are 2 key issues with spreadsheets for deployment coordination:

*1. Manual automation - it may seem like a contradiction in terms but most deployment automation scripts are manually launched at the command line by a system admin or deployment engineer. During this fundamentally manual process, a momentary typo in a script parameter can create hours of downstream trouble-shooting and repair work. If you have had any exposure to n-tier application deployment you know that there has to be a better way to do this. One customer we worked with had 2 system administrators assigned to each production deployment - one to type in the commands and another to review and verify each command (letter by letter) before it was executed. Now that's expensive.

*2. Which spreadsheet? - when the list of activities to be coordinated grows beyond a handful teams frequently need to change and update the spreadsheet. Managing the versions of the spreadsheet and tweaking it to accommodate unique steps for this release becomes a full time activity. Checking it into version control is one strategy - but is the one in version control the latest copy? Does the operations team have access to version control? Probably not.

Both of these challenges call for a solution that is lightweight and easy to use - but gives structure to the process and allows you to execute your existing automation.

We're relaunching our blog! We've got a strong new focus on the exact target our expertise and technology focuses on.

I'm really excited about our blog because it will address this target: the critcal gap between application development and IT operations - or DevOps. While I will talk about our products - I will also talk about the bigger picture in IT - such as important trends like Release Coordination, Cloud Infrastructure and Development self-service. My goal is to inform and contribute to the IT community with breaking news and thought-provoking posts.

Check out the new wikipedia entry on DevOps. Stay tuned for more.

I ran across this site a few months back Dev2Ops. The content is great - and totally focused on the DevOps problem space. In particular I really liked this article on Deployment Design Patterns. Enjoy...

I am pleased to announce that we closed a deal today with Four Points Technology (http://www.4points.com) to have our products listed on their GSA Schedule (contract number GS-35F-0553P). As the most well-known Government-Wide Acquisition Contract (GWAC), the GSA Schedule provides StreamStep with the necessary contract vehicle to sell our products to the U.S. federal government. In addition, many other public sector entities, such as state and local governments, as well as major defense contractors, can purchase from the GSA Schedule.

Four Points Technology (FPT) currently holds the GSA Schedule for BMC BladeLogic products. FPT held the BladeLogic GSA Schedule before BladeLogic was acquired by BMC, and FPT has retained the listing since the acquisition. FPT did the deal with us because they are very excited about our future. They see us being another BladeLogic potentially and they are delighted to get on our bandwagon early in the game, envisioning our success along the lines of BladeLogic's success.

You can see the BladeLogic products on FPT's GSA Schedule at the GSA Advantage website: http://www.gsaadvantage.gov

In the "What are you looking for box", enter "BMC BladeLogic" and click the "Find It!" button. Someday soon you'll be able to enter StreamStep in that search box!

You can read the full press release here.

One of most challenging things about improving a complex release management process is getting started. Here is a great article on improving release processes from http://www.cio.com - http://www.cio.com/article/print/440101 The authors point out in section 3:

"3. Get lightweight processes in place. Test them early and review them regularly."

"If there is one single guiding principle in engineering (or reengineering) a process, it is to do a little bit, review your results and then do some more. Repeat this cyclic approach until you get the results you want.

Lightweight processes are those that do not require lengthy bureaucratic approvals or endless meetings to get agreement. They usually require only the minimum acceptable level of inputs and outputs. What they lack in bulk and bureaucracy, they make up for in response to change and popular adoption!

Underpinning this approach is the thorny issue of documentation. You need to record what you did and how you did it. Otherwise, what do you review and how do you improve?"

As part of this effort the authors put in place a commercially available portal product - based on a wiki-portal approach.

But as we have found with many of our customers - Portals are generic tools for documentation and sharing. Release management has a specific set of challenges which are onlypartially covered by the portal approach.

1. Documentation - a documentation portal is only as good as the updates to it. If people forget to update it then it quickly loses currency and usefulness. In the day-to-day release process - portals can drift out-of-sight and out-of-mind - resulting in the checklist entry "Make sure you update the portal with the DB dumpfile location."

2. Process control - portals are primarily stateless repositories of lists and documentation. They don't enforce or assist with process control. And portal workflow modules, where they exist, suffer from the core problems of workflow - brittleness and maintenance complexity. In fact, "coded workflows" are antithetical to the notion of a "lightweight process".

3. Metrics - related to the lack of process control, portals don't produce metrics that assist in targeting subsequent improvement work. At best managers can use forms to measure inputs to the process in the form of requests for release activities - but the underlying process detail is lost from view. Frequently this detail - what happened and when - is where the real process improvement opportunities reside.

4. Automation - finally the goal of release management is to deliver flawless releases as efficiently as possible. Automation is a key part of achieving this goal. Portals just don't engage release automation - it's not what they were designed to do.

Conclusion

Putting in place a portal for your release team is a great first step to improving your release processes. If you don't have a way for your team to share release documentation then a portal can make a huge difference. But if like many companies today, you already have a release team portal and yet you still see room for improvement in your release processes, you should consider a lightweight release management solution like StreamStep - SmartRelease. A solution purpose built for today's release management challenges - Release Management... Simplified.