SNESCM

Scandinavian Network of Excellence
in
Software Configuration Management

Presentation abstracts:

A Quality Assurance view on Configuration Management (Lars Beck):
Quality assurance can’t exist without configuration management, and in some aspects, quality assurance and configuration management have overlapping areas of focus and interest, even in agile software development using a V-model.

How to change/evolve a SW architecture to better support CI/CD scenarios (Mauro de Pascale):
Enterprise Architecture is always seen as a problem to workaround by Agile teams. On of the reasons is that usually an EA design takes longer than an Agile iteration producing a release and when finished is often already obsolete (because of new technologies, because of new requirements, because of new feedbacks).
Continous Architecture is an attempt to mediate Agile's need to be fast and to embrace change with the benefit of a long term strategy and planned control switching from designing the software to designing the product.

Moving from past into future (Conny Enghoff):
SimCorp is a company where the biggest and most important product had the first check in into SCM system back in 1995. It has evolved ever since based on a custom-made tool stack and repository with APL and Oracle database as its core serving a steady increasing number of developers, customers and product versions.
Time has come, where a major transformation is necessary both in terms of development and delivery models, as well as the repository and tools supporting the deployment pipeline:

• The SCM system developed and maintained internally in SimCorp will be retired and a new DVCS based on GitHub will take over.
• We have moved from a classical waterfall development model to an agile approach.
• Quality control execution shifts from a batch-oriented view to continuous integration and faster feedback.

Experiences with integrating an SCM system with a binary repository manager (Sten Rosendahl):
Not all SCM systems can handle binary artifacts, but even if they can, it may be slow or cumbersome, especially in a big system where you need to baseline the usage of internal and external modules. At FIS, we decided to complement our source control system with Artifactory to optimize this process.

Micro-tutorial: Streamed lines, branching patterns (Lars Bendix):
Version Control tools are in part used for co-ordinating a groups of developers and in part for being a Configuration Management Data Base giving the history for how a product has been developed.
We do not have many different mechanisms in version control tools to handle these situations - basically we have branching and merging. So it becomes important that these two mechanisms can be used in different ways to support different situations.
In this micro-tutorial we will go through different stragegies for branching and merging and look at what advantages and drawbacks each strategy has so we can select strategies that are well suited for specific contexts.

Open Space - Naming convensions and versioning schemes, one standard to rule them all? (Sofus Albertsen, Christian Pendleton):
Disregarding time based versioning, we tend to converge towards SemVer as the standard versioning scheme. But can that standard stand alone? And what happens when the legacy part of real life hits theory?
In this open space discussion we will share stories as well as discuss a standard way of aproaching uniform versioning.

Open Space - Centralizing vs. Distributing SCM (Not GIT vs. Subversion) (Artour Klevin, Jon Nessmar):
In this Open Space we consider the two following context: The first one the organization has decided to build a dedicated team to manage all tool related responsibilities, that main purpose is to make sure that the teams have a way to deliver their software. In the second context we only dedicate responsibility of the infrastructure, either to team or buy it in the cloud. In this context development teams themselves will take responsibility for their deliveries. What we wish to discuss in this open space is how the role of a CM changes between these contexts and what the highest prioritised focus areas are.

Open Space - Towards a Configuration Management Manifesto (Lars Bendix):
A manifesto is a published verbal declaration of the intentions, motives, or views of the issuer, be it an individual, group, political party or government.
In the Agile world they have a manifesto stating the philosophy and core values of agile and giving a list of guidelines for how to be/do agile. This makes life easier for agile practitioners when they have to adapt/implement agile development - or to get back to "the beaten track" when they become dis-orientated in the jungle of different agile concepts/methods.
Maybe it was time to have a manifesto also for (software) configuration management.
In contrast to the Software Configuration Management Sales Pitches that serve to explain to outsiders what SCM is and can to, an SCM manifesto would have an "internal" purpose by guiding SCM practitioners in the right direction and making it clear what are the common values for all the different flavours of configuration management work.