From the Editor by Bob Aiello, Editor in Chief CM Journal
Thanks for joining me in sharing experiences on how to implement Software Configuration and Release Management process and best practices. CM Crossroads has been a major influence in my career for a very long time and I am extremely grateful to all of my colleagues who have helped me (by sharing their own experience) with implementing CM in large financial services firms. When I setup a source code management tool, implement a workflow system, or other process improvement initiative, people get my home phone number and are allowed to wake me up in the middle of the night. That means my methodologies have to work or I just don't get a night's sleep. CM and process improvement have been my passion for a very long time. Over the next few weeks I will be offering my thoughts on a number of key areas of CM. I hope that you will also offer me your own comments, questions and suggestions.
Some of the topics that I would like to cover in the near future are:
1. FastTrack plan for implementing CM in large organizations 2. Process Improvement - what it is and how to do it effectively 3. Overcoming resistence to change 4. Automating workflows and enforcing the process 5. Supporting compliance (e.g. SOX) or do you what version of the code is in production? 6. Repeatable builds and continuous integration 7. CM in the future - what's ahead and how you can contribute (and benefit)
Please do continue to share your views via our letters to the editor in the forums section of CM Crossroads.
I am looking forward to sharing my thoughts and ideas and I hope that you will join me!
There have been many times, in my career, where I have felt like I was sitting through the same movie that I had previously seen in an earlier assignment. I knew the ending already and yet it was challenging to sell my ideas to others around me. Trying to evangelize Configuration Management practices can be difficult at times and I must admit that I have not always been completely successful. However, I have certainly always tried to give my honest view on what needs to be accomplished in order to meet the goals of the organization. However, just plain honesty won’t always help you sell your ideas successfully. Sometimes, you also need to have an approach that makes CM compelling. This means that you must state your case effectively and win over the key stakeholders to your point of view. Many CM professionals don’t realize just how important being a good salesman is to the job of successfully implementing configuration management.
In these situations, I always try to shift the paradigm. For example, having a good lawyer who believes that you are innocent won’t help you unless your attorney presents a case that is compelling and convinces the Judge, Jury and lately it seems – the members of the media as well. You might have great ideas for how to setup your SCM solution, perfect branching/merging practices and a real ability to implement continuous integration. But if you can’t sell your ideas then you just won’t be successful. I would like this blog post to trigger a discussion on challenges that people encounter then selling CMto the organizations and also a description of approaches that work. Please drop me a line and share your own experiences in overcoming resistance to change!
I am working on the Calendar for 2009 (see below) and I would love to
get your input!
Here is the current proposed list. The first date is the due date for article submission and the second date is the publication date for the issue. If this is the first time that you are submitting an article then I strongly encourage you to get me a draft a week or two earlier than the due date. I will make every effort to help you with writing (e.g. spelling, grammer and word usage). The CM Journal is an excellent publication because all of our writers (including myself) are true trench level CM practitioners. We eat, sleep and drink Configuration Management so all of our articles are written from the powerful position of hands-on experience. We know what works and what doesn't. That also means that you don't have to be a polished writer, because we are always delighted to work with new (editorial) talent. Many of our writers go on to write books and all of our writers benefit from the experience of getting their articles published. (Consultants may find themselves a little overbooked!)
I am hoping that you will join us!
I am also always looking for people to contribute to short articles on CM tips & tricks for CM Basics.
In CM Basics, we have been covering the use of Ant, Maven 1.02 and (soon) Maven 2. These are all excellent build tools and, along with Make/GNU Make, are the core ingredients in taking a buggy, unreliable build and bringing it down to a repeatable process that runs flawlessly in 1 – 3 hours (from what used to take 1 – 3 days). I have enjoyed playing the hands-on role in this process many times and, on my last build assignment, bet the CIO and the CTO that I could fix the build process in three iterations of their current release process. (I always watch, learn, and document the current procedures before I change anything!)
One of the most popular topics in the CM field always comes back to "how do I pick the BEST CM tool?" Most people believe that picking out the right tool will solve all the big problems - so the debate rages on. Should I go with IBM's ClearCase or an Open Source product like Subversion or any number of popular CM tools on the market today. Frankly, I am tools agnostic. I have seen the worst tools (from a technical perspective) work just fine on some teams and the best tools fail miserably (usually because the company would not invest in training). So how does one pick a good CM tool?
One of the challenges with implementing a CM solution is deciding whether or not you should investigate industry standards for use by your organization. Many companies don't bother with standards and maybe that's actually a good idea. I have spent a considerable amount of time studying and working to implement industry standards and frameworks. Sometimes, they have lots of extra work that may not seem necessary or even valuable. Yet standards exist for good reasons. So should you consider using standards and frameworks when you implement your CM solution? Read on if you want to understand the do's and don'ts of adopting industry standards and frameworks.
Implementing a large scale SCM solution is an exciting, challenging and event daunting task. I worked in one company which had spent a lot of money on a particular commercial SCM tool that was for the most part not being used by the members of the firm due to the complexity of implementing the tool and the lack of support resources within the firm. Two consulting agencies had already been in and had not helped the organization setup and train the developers on the successful use of this tool. I started to help out informally with supporting the SCM effort and pretty soon found myself implementing this SCM solution from scratch. By the time I was done, I had 700+ developers using the tool with over 1700 source code repositories worldwide. We used an implementation methodology that I began calling my "FastTrack" for SCM solutions. If you would like to get on the FastTrack with me, then please read on as we share best practices for architecting successful SCM Solutions!
This is my first post in my new position as Editor-in-Chief of CM Crossroads and I would like to start by telling you a little bit about my background and the way that I approach my work. Most of my career has been dedicated to helping organizations solve problems that impact their productivity and profitability. I have always worked as a full-time employee and actively participate as a hands-on member of the technical team. That means that I am usually the admin support for the source code management tools (e.g. ClearCase/Multisite), build and release the code and (when I am really having fun) get to build the Unix machines and actively participate in the technical support of the key development, qa and production systems. Most "process improvement" professionals do not attempt to be hands-on. I try to stay technical, in part, because I love having a hands-on role so much. It also keeps me honest and only implementing processes that I am willing to live with myself. By staying technical, I get to "walk the walk" instead of just "talking the talk."
Blogs 
