You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documentation/deployment-management.asciidoc
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -43,7 +43,7 @@ Shutting down servers or starting schema migrations are typical manual tasks.
43
43
=== Master the artefact dependencies
44
44
Explicitly track and resolve the transitive run-time dependencies between deployment artefacts to ensure a transparent and traceable installation.
45
45
46
-
First, clearly distinguish between build-time, test, and run-time dependencies, as they typically have to be resolved at different times (build versus deployment), and plain build-time or test dependencies shall not be included in the release package. Refer to the pattern \ref{pat:CheckDependencies} for further details with reference to this issue.
46
+
First, clearly distinguish between build-time, test, and run-time dependencies, as they typically have to be resolved at different times (build versus deployment), and plain build-time or test dependencies shall not be included in the release package.
47
47
48
48
=== Separate environments
49
49
Separate environments for development, test, acceptance, and production (DTAP):
@@ -85,7 +85,7 @@ The reason is that service windows of operations and the domain-related business
85
85
All operation departments have regulations on how to deploy software systems and what are the preconditions to deploy them into production.
86
86
This includes, for example, that the new software has to support specialised monitoring or logging features, or that it must offer some dictated services, for shutting down or starting the server process.
87
87
88
-
Hence, for every smooth \textit{going live} process, you must always ensure that the deployment is truly performed hand-in-hand with these stakeholders.
88
+
Hence, for every smooth _going live_ process, you must always ensure that the deployment is truly performed hand-in-hand with these stakeholders.
89
89
This involves clearly communicating what version is being deployed, when it is deployed, why it is deployed, what user-visible changes will be apparent subsequently, etc.
Copy file name to clipboardExpand all lines: documentation/scm.asciidoc
+46-3Lines changed: 46 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,29 @@
1
-
:toc: macro
2
-
toc::[]
3
-
4
1
= Software-Configuration-Management
2
+
:description: comprehensive documentation about software-configuration-management.
3
+
:doctype: book
4
+
:toc:
5
+
:toc-title: Table of Contents
6
+
:idprefix:
7
+
:idseparator: -
8
+
:sectnums:
9
+
:reproducible:
10
+
:source-highlighter: rouge
11
+
:listing-caption: Listing
12
+
:chapter-label:
13
+
:partnums:
14
+
:imagesdir: ./
15
+
The devonfw community
16
+
${project.version}, ${buildtime}
17
+
5
18
6
19
_Software-configuration-management (SCM) is the application of configuration management principles in the context of software engineering_.
7
20
8
21
SCM identifies and tracks the configuration of artifacts at various points in time and performs systematic control of changes to the configuration of artifacts for the purpose of maintaining integrity and traceability throughout the whole software development lifecycle.
9
22
23
+
The following sections contain the complete compendium of https://github.com/devonfw/scm/[software-configuration-management] (SCM).
24
+
You can also read the latest version of this documentation online in the http://github.com/devonfw/scm/wiki[scm wiki]
25
+
or at https://devonfw.com/website/pages/docs/scm.asciidoc.html[scm on devonfw.com].
0 commit comments