Brad Appleton

DevOps is steadily gaining traction and currency, particularly in the world of web apps. Below you will find an introduction and some pointers to resources and further reading. Many DevOps principles have been around for a long time. This is similar to agile methods and, in some ways, a repackaging of existing principles.

Two topics that are likely to launch a development team into an impassioned discussion are development standards and development environments (IDEs, editors, etc). Combining the two topics into that of standardizing on development environments, is even more likely to spark debate. Decisions about development tools affect the day to day workings of each person on the team as well as the productivity of the team, and as such are important to discuss as a team organizes itself.

Brad Appleton, Robert Cowham, and Steve Berczuk continue to explore the role of build and deployment in configuration management. While the details may change from year to year as technology evolves, the underlying principles remain the same. Regarding building, we are going to take the opportunity to provide a guide to some of our previous articles that still hold true.

In this article, the authors discuss how software configuration fits into products and projects, beyond managing and controlling source code and other developer assets. They look at the differences between internal and external products and where project fit into the equation.

For teams practicing Agile Software development, value working software over other artifacts, a feature from the release plan is not complete until you can demonstrate it to your customer, ideally in a shippable state. Agile teams strive to have a working system ("potentially shippable") ready at the end of each iteration. Release Management should be easy for an ideal agile team, as agile teams, in theory, are ready to release at regular intervals, and the release management aspect is the customer saying, "Ship it!."

The article discusses IT governance and compliance, which tends to suggest more formal and rigorous processes. The authors explore how you can agile practices with in the framework of governance and compliance rules and regulations.

In this January article, the authors look back at the software development landscape in 2007 and make predictions for 2008.

For some lean/agile practitioners, the idea of maintaining traceability among different development artifacts is nonsense. There are times, though, when traceability is required and other times when it's highly valuable. We need to develop a value mindset of transparency in our processes and approach so that traceability requirements can be satisfied with minimal effort.

Taking an lean-agile slant on metrics for configuration management, the authors focus on ways to measure the value CM and SCM adds to the project and product and how to measure flow and waste.

In this article, the authors explore translation of object-oriented design principles to codelines, branching, and promotion. In addition, they expand on the concept of moving from task-based development (TBD) to project-oriented branching (POB).

This month we do a bit of a context switch from the world of parallel development to the world of concurrent, parallel, and distributed systems design (and then back again). The purpose is to see if any of the same patterns of concurrent, parallel, and distributed processing apply to the case of concurrent, parallel, and distributed development.

How can software configuration management be compatible with agile software development? Aren’t the two diametrically opposed to one another? Sometimes it may seem that way. There is a commonly perceived tension between SCM and development agility that makes it difficult to achieve an effective yet precarious “equilibrium” between the two: