-
Story
-
Resolution: Done
-
High
-
None
-
None
At the moment everything is tied to 'latest' which is called 'snapshot'. This imposes a huge non-deterministic risk for actual deployments and makes it really hard to reference script / artefact versions in e.g. bug reports or questions.
The main issue is that the maven style 'snapshot' is used without the actual maven implementation using distinct versions internally. maven allows to point to latest (with snapshot) but is versioned in the metadata. So you always can tell what 'version' you are using.
https://nexus.onap.org/content/sites/raw/org.onap.demo/heat/ONAP/1.1.0-SNAPSHOT
omits this information as it is just a pointer to latest. You can download things at 9:00 am in the morning but get a totally different result at 9:01 am (pick any time later, one minute to just make a point)
the same is true with docker image tagging. running the exact same script a minute later can pull in new docker images references as the same snapshot tag.
Definition of done:
- Scripts can be referenced with a proper version string
- docker images can be referenced with a proper version string
- a changelog is maintained alongside version increments
I do understand that this will need some work but the current situation is depending on temperature as well as moon and star constellations
btw. http://kief.com/the-conflict-between-continuous-delivery-and-traditional-agile.html
Friction point: snapshot/release builds
Many development teams divide software builds into two types, “snapshot” builds and “release” builds. This is not specific to Agile, but has become strongly embedded in the Java world due to the rise of Maven, which puts the snapshot/build concept at the core of its design. This approach divides the development cycle into two phases, with snapshots being used while software is in development, and a release build being created only when the software is deemed ready for release.
This division of the release cycle clearly conflicts with the Continuous Delivery philosophy that software should always be ready for release. The way CD is typically implemented involves only creating a build once, and then promoting it through multiple stages of a pipeline for testing and validation activities, which doesn’t work if software is built in two different ways as with Maven.
- blocks
-
INT-344 All R1 AAI Model-loader jenkins jobs BUILD FAILURE since 16 nov on missing sdc-distribution-client 1.1.32 - should be 1.1.50
- Closed
- is blocked by
-
AAI-511 All R1 AAI Model-loader jenkins jobs BUILD FAILURE since 16 nov on missing sdc-distribution-client 1.1.32 - should be 1.1.50
- Closed
-
INT-333 Post recording of R1 vFirewall E2E test - As verification reference
- Closed
-
INT-344 All R1 AAI Model-loader jenkins jobs BUILD FAILURE since 16 nov on missing sdc-distribution-client 1.1.32 - should be 1.1.50
- Closed
- relates to
-
INT-189 TAG All builds when Deployment CI passes
- Closed
-
LOG-300 CD: OOM framework for continuous E2E deploy validation of tagged commit/merge trigger docker snapshots
- Closed
-
INT-120 Deployment Status Sanity - Daily auto E2E verification status of the build
- Closed
-
LOG-332 Deployment CI/CD Integration Jenkins job using OOM-K8S - to validate branch
- Closed
-
INT-300 CI-CD For ONAP master branch
- Closed
- mentioned in
-
Page Loading...