--- title: "Releases & Builds" canonical: "https://docs.vaultspeed.com/space/VPD/3011510333/Releases%20%26%20Builds" format: markdown --- Modelling your sources in VaultSpeed happens through a series of releases (with internal builds behind them). You start by creating an initial release for a source that you can edit. When you finally complete your source release, it will be ready to be integrated into your Raw Data Vault model. When you want to make more changes to your source model, or the model has changed on the source itself, you can integrate those by creating a new release that allows you to work further on top of what you already modeled before. To create a source release navigate to the **Releases & Builds** tab : ![image](media://bea2773f-65aa-40d3-b1d2-a60f53ed876f) # Creating a first release Click '+Release' to add a new release and fill in the release number and comment: ![image](media://76d68186-9a6c-448b-a1a4-44a17758c697) > 📝 Special characters are not supported in the comments! After clicking the 'Create' button, 3 tasks are started in order to create a release: - Read info from source system (executed by the VaultSpeed Agent). - Putting generated CSV files (executed by the VaultSpeed Agent). - Create new release and first prototype build. These tasks may take a while to complete.  Track the progress of these tasks by opening the running tasks window: ![image](media://43f040bd-9024-41c7-9bed-33ad5f809ef0) You can refresh the status of the tasks by clicking the refresh icon at the top right. Once all the tasks have finished, you don’t see your release yet on the release overview. It will show up once you pres the 'refresh' icon on the releases screen. ![image](media://4639dcd5-9152-4d8c-85d5-a8fad505b8e5) The **Release status **of a new release is "WORK IN PROGRESS", meaning this source is not yet ready to be included in a Data Vault. And the lock icon at the right is open which means that the source model has not been locked yet and can still be edited. # Release Definitions Before creating releases, it is important to understand the different types of releases in VaultSpeed: - **Base Release**: The release on which a new release is based. This does not necessarily have to be the immediately preceding release; it can be any historical release, provided it has a locked Data Vault Release. - **Historical Release**: Any release that is not the currently Active release. - **Previous Release**: A specific Historical Release Version, specifically the release immediately preceding the current one (version -1). - **Active Release**: The last created release where the base tables and source parameters are fully synchronized. It can be in an edit, saved, or locked state. # Creating Subsequent Releases When creating a new release from an existing one, you now have more flexibility in choosing your starting point. ### Base Release Selection When creating a new source release, you can select a **Previous Release** to base the new release on. You can choose from: - **Locked Historical Source Release**: Use any historical release that has a locked Data Vault Release. > ℹ️ Only releases that were saved or locked after Release 6.0 can be selected as Historic base releases. - **Active Source Release**: Use the most recent release as your base. Can be in any state (Edit, Saved, Locked). - **None(no previous release)**: No previous release, start with a completely fresh release based only on the latest harvested data. The "Keep" options will be disabled (since there's nothing to keep), and "Re-import" will be forced, as the system needs to harvest new data from the source to create the release. ![image](media://3a5538f3-fc60-4a2c-8e02-61f0c180a9cc) ### Keep Options The "Keep from previous release" options allow you to determine how much of the model from the Base Release is carried over to the new release. - **Everything (Re-import disabled)**: The new release will contain the exact same model as the selected base release. - **Everything (Re-import enabled)**: The new release contains the model from the base release, updated with the newly harvested model from the source. - **Objects and attributes (remove constraints)**: All Object and Attribute data from the base release is kept. All constraint configurations (e.g., manually defined keys) are removed. The constraints will be based only on the data harvested from the source. If **re-import** is **enabled**, then the latest source data will be harvested and used. If **re-import** is **disabled**, then the source data, as harvested by the base release, will be used. - **Objects (remove attributes and constraints)**: Only the Object data is kept. Constraint data is removed, and all user-defined attribute configurations (e.g., attribute signatures, data types, names) are removed. Attributes are reset to the harvested state. If **re-import** is **enabled**, then the latest source data will be harvested and used. If **re-import** is **disabled**, then the source data, as harvested by the base release, will be used. - **Nothing**: No data is retained from the base release. The new release reflects only the latest harvested data (if re-import is enabled) or the data harvested when the base release was created (if re-import is disabled). ### Re-import Disabling the 'Re-import source metadata' flag will create a new release without reading from the source again. This is useful when you have to make a small change to the previous release and nothing has changed on the source database itself. Or because the source has changed on the database in the meantime but you do not want to include those changes yet. > 📝 When a source is renamed, or the source_physical schema is changed, you must do a new metadata harvest (Re-import source metadata). Otherwise you could get incorrect objects/attributes ### Source Parameter Change Validation Before the user is allowed to create the new release, the system checks whether the source parameters have changed compared to the base release. If changes are detected, a report is displayed to the user. You must review and click "Accept" to proceed. This ensures you are aware of potential differences in the Data Vault build due to intermediate parameter changes. ![image](media://3e880882-bfb0-43ef-bd8e-c1176269fc12) The system gives the user an overview but no real explanation of the impact of the parameter. The impact of the parameter can be found in the parameter descriptions itself, an example of a few changes we see regularly: #### Impact of a change on REFERENTIAL_INTEGRITY_VALIDATED Changing REFERENTIAL_INTEGRITY_VALIDATED from N to Y creates a significant shift in how the generated code handles missing references: **With N (current):** - Unknown references get an "~UNK~" replacement value in links - Records load immediately, even with missing parent keys **With Y (new behavior):** - Creates error tables in the extraction layer for each table - Records which have missing references go to the error tables instead of being loaded - Each foreign key gets a specific ERROR_CODE field (like ERROR_CODE_ADDR_CIAI) - Records only load once the referenced parent becomes available **Key impact:** You'll get better data quality, but potentially delayed loading. Records wait in error tables until their references are resolved, rather than loading immediately with unknown placeholders. Note: This applies only when the table's primary key differs from the business key. #### **Impact of a change on EARLY_ARRIVING_FACTS** **EARLY_ARRIVING_FACTS = Y:** - Loads Hub business keys from both the parent object AND all related child objects - Prevents issues when keys arrive out of order or aren't all present in the parent - Creates Hub records even when the parent data is missing **EARLY_ARRIVING_FACTS = N:** - Loads Hub business keys only from the parent object - Child objects must wait for parent data to be available first **Key Use Case:** This only applies when primary key = business key (PK = BK) . When PK ≠ BK, use REFERENTIAL_INTEGRITY_VALIDATED instead. **Real Example:** If invoices reference customer 2 but customer 2 doesn't exist in the customer source yet, setting Y will still create the customer Hub record from the invoice data. This prevents broken references and allows data loading to continue . The parameter essentially future-proofs your data vault by creating placeholder Hubs that can be populated later when the actual parent data arrives. #### **Impact of a change on CDC_LOGPOSITION_AVAILABLE** CDC_LOGPOSITION_AVAILABLE controls whether log position data is used for CDC records: **CDC_LOGPOSITION_AVAILABLE = Y:** - Enables log position tracking from source database system - Combines cdc_timestamp + cdc_logposition (based on parameter CDC_LOGPOSITION) to uniquely identify each CDC record - Creates attribute (based on parameter CDC_LOGPOSITION) in signature objects (SAT, LKS, LDS, NHL, LAS, PIT, BVV) - Captures unique incrementing values like SCN, LSN, or offset for proper change ordering **CDC_LOGPOSITION_AVAILABLE = N:** - No log position tracking - Relies only on cdc_timestamp for record identification - May have issues with records having identical timestamps **Key Impact:** Setting to Y provides better CDC record uniqueness and chronological ordering, especially important when multiple changes occur at the same timestamp. Essential for reliable CDC processing when your source system provides log position data. # Release State > ⚠️ **Warning about losing changes:** If the currently active release for this source has NOT been saved yet, you will be warned that creating a new release will remove all unsaved changes. After a new release is successfully created, it becomes the **Active Release** and is editable. All other releases are effectively locked for editing. # Deleting a Release You can delete any release that is **NOT** used in a Data Vault yet. When deleting a release: - A warning message will appear asking for confirmation. - All release and version metadata associated with that release will be deleted. If you delete the active release, the system will revert to the state before that release was created. # Parameters ## Source Parameters Source parameters are not versioned as part of a Source Release. Only when you lock a Data Vault Release, are the Source parameter values saved. This means that when you create a new source release based on a historic release, the Source Parameters could have changed in the meantime, since they are not reset to values they had when the base release was created. This could cause unexpected changes in the Data Vault configuration later on, and is why VaultSpeed shows a warning when it detects these changes. ## Source Object Parameter Source Object Parameters are versioned as part of a Source Release, when a parameter for an object is modified and the release is saved, then this parameter value will be used in the Data Vault creation and code generation. When selecting a historic base release, then this parameter value will be taken from the object in that base release. If an Object Parameter has not been modified (object specific flag False) then its value comes from the Source parameter settings. When changing an object parameter at the source level, this change is propagated only to the objects in the currently active release which have the object specific flag set to false. When creating a New release, with, or without a base release selected, then all the Object Parameter values with object specific flag set to false will take over the value from the parameter at the Source level. > Macro (drawio)