Home 
Behaviorally Speaking Behaviorally Speaking: Continuous Integration- Managing Chaos for Quality!
Behaviorally Speaking Behaviorally Speaking: Continuous Integration- Managing Chaos for Quality!
|
| Many CM practitioners work for large global companies where development teams can be as small as 10 developers or as large as hundreds spread out worldwide. My own work involves coordinating across numerous physical locations including the United States, Europe, and Asia. Some developers need to work in isolation so we teach and support branching and merging of code. Otherwise their builds could break on a daily basis with significant loss of productivity. But this can obviously create some serious integration challenges that could potentially cause a critical project to fail. How can we make sense of this chaos and still secure our code? It should come as no surprise that these challenges highlight the value of CM and continuous integration is a key requirement for making all of this work.
Glorious Isolation Developers get really annoyed when they are trying to build a release and it fails as a result of a compile dependency that is found in code that someone else owns and maintains. For large scale C++ applications this can be a daily experience of frustration that can significantly impact productivity. If you give many developers a choice they will gladly postpone integration until the very last minute. Yet integration testing can be very complicated and problems can surface that may be a result of code that just cannot coexist in the same application. Some developers believe that Integrating early and often can take more time away from the actual development and coding effort as perceived by many developers. Most testing professionals believe that early and continuous integration helps to uncover potential problems that could more serious and difficult to resolve later in the development process. I have seen many occasions when the project manager has felt that when deadlines are looming it is better to stay focusing on getting my deliverables completed, regardless of what be uncovered later. (At least I can say that I made my deadline…) Off-shore is Making CM Really Essential! Coordinating a large codebase can be complicated under the best of circumstances. There are many challenging questions and issues that must be addressed. How do I setup separate branches to manage the development effort and how do I control the integration process? This is a great time for CM practitioners to really show their value to the organization! CM to the Rrescue! Organizations that have these challenges can really benefit from Software Configuration and Release Management best practices. These challenges can really allow CM practitioners to show their value and contribution to the success of the organization. As always we need to stay close to the goals. Don’t create an overly complex scheme that cannot be understood by the average developer. Do write CM Plans to document standard naming conventions for Version Labels and Branches. Publish them to the rest of the organization. From a process point of view we only allow the Buildmeister to create branch and version label “types” (which declares them for use by the other developers). Developers use the branches (“types) created (or declared) by the Buildmeister. We don’t dictate the actual naming conventions, we just require that they exist and that they are published via a CM Plan (on a developer website). Best CM practices help developers to communicate more effectively. I usually “lock” version labels and branches when developers claim that they are done. This forces them to contact me if they realize that they have more to do and then I can give the test team a call to let them know that more work is headed their way as well. Change is good. It’s exactly why we have jobs and we need to get better at managing change. Private Branching Some developers don’t “check-in” their code because it will break someone else’s build or it is just not ready for review. This is really bad because code is only really secured if it has been checked into the repository. A “private” branch can allow a developer to checkin his changes and still not affect the code. I am personally a big fan checking out the file “reserved” on both the main development branch and the private branch if possible to avoid painful (and time consuming) merges later. Rebasing for Beginners One of the best techniques that I have personally seen from Rational’s UCM is the idea of “rebasing” (if this is actually from some other vendors earlier tool please let me know!). With this technique a developer pulls in changes to his development branch and checks his compile before he commits his changes back onto the main branch. It’s actually a little extra work, but it can avoid many problems in the future. Effectively, this technique brings changes from the main branch to the development branch to resolve any integration issues. Then the “cleaned” development branch is merged onto main in what is a relatively safe operation (assuming it is done right after the rebasing). Continuous Integration? It’s my opinion that continuous integration will work in groups that are very cohesive and located in physically the same location. I am personally not convinced that this will work well in global organizations on large projects, in the companies that are involved with large scale financial services. In this case there is a very great risk of continuous integration causing a lot problems and wasted effort. I would prefer to recommend “just enough” integration and that depends a lot on the culture of the organization and the people involved. Many investment firms seek and reward financial professionals who thrive on risk and challenge of organizational chaos. Some IT professionals sit next to traders on exciting trading floors where risk is organizationally acceptable, if not required. Many of these professionals do and amazing job with little or no formal software development processes. People, Process and Technology This is exactly where process meets people in Software Process Improvement. The CM practitioner can certainly make recommendations and publish best practices but always remember that this is where our work is part science and part art. People skills including negotiating and communicating are the critical success factors. I have personally seen some really bad process models work fine, because several very smart developers were determined to make it work at all cost. This sounds a little like the heroics that process improvement advocates are always warning against. But I am really just emphasizing that processes must be in alignment with the culture of the organization or they just won’t help the business and meet the organizational goals. Remember in continuous integration it is the developers doing the actual work (which can be significant) and we all need to focus more on the People part of People, Process and Technology. Bob Aiello is a Senior Editor for Crossroads News and an Associate Director at a major financial services firm in NYC, where he has company wide responsibility for Software Configuration and Release Management best practices. Bob is on the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he is also the chair of the CM SIG which meets in Midtown NYC. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra.and Release Management best practices. Bob is on the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he is also the chair of the CM SIG which meets in Midtown NYC. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra. You can reach Mr. Aiello by email at raiello@acm.org
Set as favorite
Bookmark
Email this
Hits: 8569 Trackback(0)Comments (0)
|
| Last Updated on Tuesday, 01 April 2008 11:01 |
TrackBack URI for this entry
Subscribe to this comment's feed