Artifact Summary

An Artifact Summary Page is a centralized view where all newly created artifacts and modifications to existing artifacts are listed before they are published to the Live (Production) environment.

Key Features of the Artifact Summary Page:

• Holds Unpublished Artifacts: It stores all newly created artifacts, and any modifications made to existing artifacts until they are ready to be deployed.

• Acts as a Staging Area: Users can review and manage artifacts before pushing them to production.

• Linked to Branches: In the Basic Sandbox, artifacts are parked in the General branch until they are published.

• Navigation: Users can access this page from the relevant artifact list pages, such as Apps, Data Tables, Reports, Workspaces, Users, etc.

• Selective Publishing: Not all artifacts need to be published—only specific artifacts created for production use.

Understanding placeholders in the Artifacts Summary page

1. Artifacts: Here is a compilation of newly generated items or alterations implemented in the pre-existing artifacts.

2. Artifacts Category Drop-down: This dropdown menu encompasses a variety of artifact categories. Upon selecting a category, the corresponding list of artifacts for that specific category will be displayed.

3. Search: The search field enables you to input keywords, facilitating the extraction of relevant artifacts based on your input.

4. Filters: Apply filters to artifacts by Change type, Created date, and Workspace.

5. Expand all: This feature offers essential details regarding the nature of modifications made to the relevant artifact, such as whether it was created anew or updated.

6. Deploy to Live: This button is utilized to publish, deploy, or transfer the artifact to the live environment.

7. Admin: The hamburger menu provides an option to discard all changes made to the artifacts (both created and updated) in the branch.

8. Deployment Log: A deployment refers to either an individual or a set of artifacts that are collectively published to the Live environment. This interface furnishes details about a deployment (publish) from the Development (Dev) branch to the Live environment, including the timing and the specific artifacts deployed during that operation.

   To reverse a deployment, utilize the "Rollback" option, which allows you to undo the most recent deployment. This action removes the published artifact creations and modifications from the Live environment. It's important to note that rollback is applicable only to the latest deployment.

9. Regular View & Timeline View

   1. Regular View: Within this view, you'll discover a roster of all the artifacts that have been either newly generated or modified, along with the timestamps indicating when they were created.

   2. Timeline View: Within this view, you'll encounter a compilation of individuals who have either created or updated the artifacts, along with the respective timestamps indicating when these actions were performed.

10. Manage Stages: The Dev and Live sandbox environments or stages are distinguished by colored buttons. If you wish to customize these default colors according to your preference, you can utilize the Manage Stages option to update the colors associated with the stage icons.

Managing Artifact Dependencies for Deployment

In Quixy, we collaborate and link diverse types of artifacts to create a functional solution. These artifacts are interconnected and depend on one another to achieve specific functionalities.

As the sandbox necessitates the deployment of artifacts to the live environment after their creation or modification, it's crucial to deploy related artifacts either simultaneously or ensure that the parent artifact is deployed first, followed by the dependent (child) artifact.

In the event of a discrepancy during artifact deployment—attempting to deploy a dependent (child) artifact to the live environment before deploying the parent artifact—the platform will present an error dialogue box, indicating a dependency issue. This error notification not only alerts about the problem but also furnishes information on the artifact dependency within the dialogue box. This ensures awareness and prompts users to proceed with deploying or publishing the dependent artifact before deploying or publishing the actual artifact.

The following examples illustrate how the artifact dependency mechanism operates:

1. When attempting to deploy an "App," the system will verify the availability of the workspace in the next stage. If the workspace is not available, the system will generate an error message prompting the deployment of the workspace.

2. In the case of deploying an "App (with Look ups)," the system will examine the availability of lookups in the next stage. If the lookups are not present, the system will issue an error message, necessitating the deployment of lookups.

3. For the deployment of an "App event (Data function)," the system will validate the availability of both the App and the data table in the next stage. If either is unavailable, the system will prompt an error, urging the deployment of both the App and the data table.

4. When deploying a "Report," the system will check for the availability of the data source in the next stage. Should the data source be absent, the system will generate an error message, indicating the need to deploy the data source.

5. In the deployment of a "List Screen (with App and Report used in Data action)," the system will verify the availability of both the App and the Report in the next stage. If either is not available, the system will display an error message, signaling the necessity to deploy both the App and the Report.