We offer project services in the areas of system architecture and engineering, particularly Continuous Delivery, DevOps, SCM and ALM. Operationally, depending on how you slice your roles, you can ask for our services to support different roles and functions including: build management, system integration, deployment management, configuration management, release management, development, operations.
Besides operational, leading hands-on support, we support conceptually by introducing, shaping or streamlining your development and delivery process and align it with current state of the art insights.
Please contact us if you have any questions or want to check whether a cooperation may make sense.
Please find below a summary of our definitions and unique approaches to the architecture and engineering disciplines Continuous Delivery, DevOps, SCM and ALM. For further details, please consult Michael's books.
Continuous Delivery
Continuous Delivery (CD) is a design practice to streamline the process of delivering software. CD is based on continuous inspection, continuous integration and continuous deployment. As a result, new releases can be pulled to target environment almost at any time, with zero-downtime.
CD underpins an approach that all code changes are entering a pipeline to production, staging artifacts from the development team to the final release in production.
The pipeline is not a "fire-and-forget" tube, rather both ends are connected with each other, similar to a "torus", or more commonly, a "doughnut". The process and the infrastructure must enable the team to promote
every single change to production, if you want to do that, however.
CD pays special attention to the development of software and its smooth and frequent transition to production.
Figure 1:
Continuous Delivery has the concept of the delivery pipeline, which models the value stream map of getting software from inception to transition.
|
DevOps
DevOps is a mix of patterns intended to improve collaboration between development and
operations. DevOps addresses shared goals and incentives as well as shared processes
and tools. Because of the natural conflicts among different groups, shared goals and
incentives may not always be achievable. However, they should at least be aligned with
one another.
DevOps respects the fact that companies and projects have specific cultures and that
people are more important than processes, which, in turn, are more important than tools.
DevOps accepts the inevitability of conflicts between development and operations.
DevOps advocates a closer collaboration between all stakeholders that are involved in the software development process. It delivers a holistic approach to software engineering.
Figure 2: DevOps links software development to operations. Both are based on business.
Traditionally, software development is influenced by Agile methods, whereas operations is influenced by service
management.
|
Software Configuration Management (SCM)
Software configuration management consists of four major functions:
o Configuration identification—Select and identify all configuration items and establish baselines on them so you can then control, audit, and report changes.
o Change control—Control changes to configuration items.
o Configuration audit—Ensure correctness, completeness, and consistency of baselines by examining the baselines, configuration items, and related processes.
o Status accounting—Report on the status of all configuration items throughout their lifecycle.
Figure 3: Artifacts that are updated
continuously and are of special interest are put into configuration management. Sources
and tests are put into version control; libraries are put into distribution management.
SCM is mainly about access to project artifacts. This includes not only tracking artifact
versions over time, but also controlling and managing changes to them. Whereas
in traditional SCM scenarios, you track every artifact, in an Agile approach, you’ll
focus on final deployment units, including documents that
influence the project (like requirement documents) and deployment units (like EARs, WARs, and JARs).
|
Application Lifecycle Management (ALM)
Agile ALM enriches ALM with Agile strategies. In my opinion, ALM is based on
software configuration management (SCM). SCM, in turn, is based on basic version
control. An Agile ALM enriches a traditional ALM with Agile values and strategies. With a
focus on communication and collaboration, ALM processes already have the prerequisites
to support Agile software development. An Agile ALM has its major focus on
human interaction (“peopleware”), increasing their communication and interactions
by implementing Agile strategies (like continuous integration) and always weighing
value and effort. The Agile approach uses lightweight tools as needed, based on concrete
requirements.
Figure 4: Agile ALM
enriches ALM with Agile
strategies. ALM is heavily
inspired by and based on
configuration management,
which in turn is based on
version control.
|