Nort Concepts: Difference between revisions
| Line 46: | Line 46: | ||
=The Release Sequence= | =The Release Sequence= | ||
<font color=red>Keep in mind that for a snapshot release, the snapshot version is already in the workarea. For a dot release, it is not, so the sequence is a bit different.</font> | |||
The release sequence consists in the following steps: | The release sequence consists in the following steps: | ||
# The release logic insures that the [[#Current_Version|current version]] is a [[#Snapshot_Version|snapshot version]]. The release fails if it encounters a [[#Dot_Version|dot version]] in the work area. | # The release logic insures that the [[#Current_Version|current version]] is a [[#Snapshot_Version|snapshot version]]. The release fails if it encounters a [[#Dot_Version|dot version]] in the work area. | ||
# <font color=red>Release qualification: test, what else?</font> | |||
# All tests are executed. | # All tests are executed. | ||
# If at least one test fails, NORT reports and fails. The work area is guaranteed to be left in the exact state it was found before the release sequence was initiated. | # If at least one test fails, NORT reports and fails. The work area is guaranteed to be left in the exact state it was found before the release sequence was initiated. | ||
# If all tests pass, the artifacts corresponding to the release are built and placed in a staging directory in the work area (usually the target directory). If the artifact building fails, NORT reports and fails. The work area is guaranteed to be left in the exact state it was found before the release sequence was initiated. | # <font color=red>If release qualification passes, start the build sequence.</font> | ||
# <font color=red>If the build sequence passes, start the installation sequence</font> | |||
# If all tests pass, the artifacts corresponding to the release are built and placed in a staging directory in the work area (usually the target directory). If the artifact building fails, NORT reports and fails. The work area is guaranteed to be left in the exact state it was found before the release sequence was initiated. | |||
# Installed in the corresponding artifact repositories. Usually, JARs are installed under their corresponding artifact directories and binary releases are installed under their corresponding "release" modules, both in the local Maven repository. For more details about artifacts and what repositories are they installed into, see "[[#Release_Artifacts|Release Artifacts]]" section. | |||
# The [[#The_Installation_Sequence|installation sequence]] is automatically initiated, unless "release" command was configured to stop after execution. | # The [[#The_Installation_Sequence|installation sequence]] is automatically initiated, unless "release" command was configured to stop after execution. | ||
# The local workarea version metadata is tentatively incremented according to the rules described in the "[[#Release_Types|Release Types]]" section. | # The local workarea version metadata is tentatively incremented according to the rules described in the "[[#Release_Types|Release Types]]" section. | ||
Revision as of 02:17, 17 November 2016
Internal
Overview
Dot Version
A dot version is a label designating a specific point in the evolution of a software project that does not contain a "SNAPSHOT" fragment. Example: "1.2.3". A dot version associated with an artifact indicates that the artifact was built based on source code that passed all the tests and it is ready for public consumption.
Snapshot Version
A snapshot version is also label designating a specific point in the evolution of a software project, indicating that the source code tree is under development at that point in time. Example: "1.2.3-SNAPSHOT-5". Normally, a "snapshot versioned" artifact should never be used outside the development process. The associated snapshot releases are necessary when dependent projects under development, themselves having a snapshot version, require new functionality or defect fixes of their dependencies. In that situation, the dependency releases a snapshot release, the dependent updates its metadata to point to the newly released dependency snapshot release, and its development continues. When the dependent is ready for a dot release, first the dependencies are "dot released" and then the dependent is "dot released". NORT provides logic to automate these workflows.
Current Version
The current version of the project is the <version> information written into the POM file in the work are of a project.
The current version is always a snapshot version, as projects are continuously evolving and they are in principle open for new functionality and defect fixes.
A version becomes a dot version during the release process. However, a dot version never lasts in a work area, it is briefly used to build the corresponding artifacts (sources and binaries), which are by default installed in their corresponding repositories, as part of the release process. If all goes well the current version is immediately upgraded to the next logical SNAPSHOT. If something goes wrong, the current version remains set to the SNAPSHOT that failed to become a dot version, until the developer fixes the problem and repeats, successfully, the release process.
Released Version
A version becomes a released version when an artifact associated with it is made available in an artifact repository. Normally, only artifacts associated with dot versions should be publicly available.
Release
A release consists in a sequence of interactions with the local project work area, the build system metadata, and various external source code and binary repositories. All types of releases end with the creation of a set of valid release artifacts, which are written into the local work area. By default, if all goes well, the release continues by default with the publishing of the artifacts in their corresponding repositories and, possibly, with the installation of the binaries in a location that makes them available for use. At the end of the release process, the work area is automatically updated to the next snapshot current version.
Release Types
Major
Minor
Patch
Snapshot
Custom
For syntax details see the release command.
The Release Sequence
Keep in mind that for a snapshot release, the snapshot version is already in the workarea. For a dot release, it is not, so the sequence is a bit different.
The release sequence consists in the following steps:
- The release logic insures that the current version is a snapshot version. The release fails if it encounters a dot version in the work area.
- Release qualification: test, what else?
- All tests are executed.
- If at least one test fails, NORT reports and fails. The work area is guaranteed to be left in the exact state it was found before the release sequence was initiated.
- If release qualification passes, start the build sequence.
- If the build sequence passes, start the installation sequence
- If all tests pass, the artifacts corresponding to the release are built and placed in a staging directory in the work area (usually the target directory). If the artifact building fails, NORT reports and fails. The work area is guaranteed to be left in the exact state it was found before the release sequence was initiated.
- Installed in the corresponding artifact repositories. Usually, JARs are installed under their corresponding artifact directories and binary releases are installed under their corresponding "release" modules, both in the local Maven repository. For more details about artifacts and what repositories are they installed into, see "Release Artifacts" section.
- The installation sequence is automatically initiated, unless "release" command was configured to stop after execution.
- The local workarea version metadata is tentatively incremented according to the rules described in the "Release Types" section.
Release Artifacts
A release my produce one of the following artifact types:
JAR Libraries
Binary Distributions
Binary distributions are usually ZIP file containing everything an application needs in order to be installed on a new system. The binary distribution include libraries, wrapper scripts, release notes, documentation and possibly other artifacts.
The recommended technique to build complex binary distributions is to add a dedicated "release" module to the project and let the Maven assembly plug-in to handle the process. The details are described in the "Building a Maven Complex Release Artifact" article.
If a project has a binary distribution that is built by Maven, NORT will publish it in the local Maven repository, under the "release" module of the project.
Binary distributions may be built using a mechanism different from Maven, but irrespective to how the artifact is built, the release sequence ends in its publishing them in some form of local binary repository.
The Build Sequence
The Installation Sequence
The installation sequence consists in the following steps:
- a
New Project Initialization
The command that carries out a new project initialization is nort initialize.
TODO:
- Verify that the POM of the new project contains the definition of maven.build.timestamp.format and release_date, as required by "Nova Ordis Utilities Version Metadata Handling" instructions. If it does not, inject it.