Difference between revisions of "Guides"
(Created blank page) |
|||
Line 1: | Line 1: | ||
+ | =Source Control Management= | ||
+ | ==Key Features== | ||
+ | |||
+ | '''Source Control Management (SCM) Integration & Tooling''' | ||
+ | |||
+ | Integration with GIT and Perforce. Conveniently check-in/out, diff history within the AMI web-based dashboard builder. | ||
+ | |||
+ | '''Multi-file Linker''' | ||
+ | |||
+ | Dashboards can be comprised of multiple files meaning components can be logically separated for independent management/version control. | ||
+ | |||
+ | '''Abstraction''' | ||
+ | |||
+ | Functionality can be marked virtual and overridden in another file, allowing for dashboard designers to abstract out functionality for custom implementation. | ||
+ | |||
+ | '''Refactoring Tool''' | ||
+ | |||
+ | Components can safely be renamed and/or moved between files. The tool automatically updates and moves dependencies as necessary with naming conflict resolution. | ||
+ | |||
+ | '''Dashboard File Stabilization''' | ||
+ | |||
+ | Changes to a dashboard result in minimum/localized changes to the underlying file. Components can be set to defaults to avoid noisy/unintended changes. | ||
+ | |||
+ | ==Benefits== | ||
+ | |||
+ | '''Team Collaboration''' | ||
+ | |||
+ | By logically dividing a dashboard across files, Teams can simultaneously work on sub-components of the dashboard. | ||
+ | |||
+ | '''Reusable Components''' | ||
+ | |||
+ | Scripts, datamodels, widgets and entire dashboards can be written once and then reused across dashboards. | ||
+ | |||
+ | '''Dashboard Tracking, Versioning, Branching''' | ||
+ | |||
+ | As AMI files are managed by source control, they can be used to label versions of a dashboard, compare versions and manage branching. | ||
+ | |||
+ | '''Merging Independent Projects''' | ||
+ | |||
+ | Existing dashboards can be incorporated into new dashboards making it easy to build super-dashboards cross-incorporating functionality | ||
+ | |||
+ | '''Enterprise Deployment Strategy''' | ||
+ | |||
+ | Treat AMI files just like any other resources that are managed through deployment strategies, such as uDeploy, TeamCity, etc. | ||
+ | |||
+ | '''Dashboard Extension''' | ||
+ | |||
+ | Extend existing dashboards for regional/business line specific usage without needing to maintain multiple near duplicate dashboards. | ||
+ | |||
+ | ==Full Backwards Compatibility== | ||
+ | |||
+ | '''File''' | ||
+ | |||
+ | Loads existing dashboards and automatically converts to the new format. Note: files are still json with the same general structure, just less clutter/redundancy. | ||
+ | |||
+ | '''Usage''' | ||
+ | |||
+ | Users & dashboard developers can continue to develop/maintain dashboards without change. Changes are purely additive, existing functionality has not been changed nor removed. | ||
+ | |||
+ | '''Split Dashboards''' | ||
+ | |||
+ | Split existing dashboards into separate files for better SCM management. | ||
+ | |||
+ | '''Combine Dashboards''' | ||
+ | |||
+ | Utilize multiple existing dashboards to create a single super-dashboard. | ||
+ | |||
+ | ==Key Concepts== | ||
+ | '''Dashboards vs. Layout''' | ||
+ | |||
+ | Prior to Source Control Management (SCM), a ''Dashboard'' was backed by a single ''Layout'' file, so the terms were interchangeable. With SCM, a ''Dashboard'' can be an amalgamation of multiple ''Layout'' files so the distinction matters: | ||
+ | |||
+ | *Layout: an individual .ami file which contains a set of source definitions such as Panels, Datamodels, Relationships, AmiScript, etc. | ||
+ | *Dashboard (Root Layout): the .ami file that is directly opened (ex: File > Absolute File - Open) is considered a Dashboard, or more specifically the Root ''Layout'' |
Revision as of 05:51, 31 March 2021
Source Control Management
Key Features
Source Control Management (SCM) Integration & Tooling
Integration with GIT and Perforce. Conveniently check-in/out, diff history within the AMI web-based dashboard builder.
Multi-file Linker
Dashboards can be comprised of multiple files meaning components can be logically separated for independent management/version control.
Abstraction
Functionality can be marked virtual and overridden in another file, allowing for dashboard designers to abstract out functionality for custom implementation.
Refactoring Tool
Components can safely be renamed and/or moved between files. The tool automatically updates and moves dependencies as necessary with naming conflict resolution.
Dashboard File Stabilization
Changes to a dashboard result in minimum/localized changes to the underlying file. Components can be set to defaults to avoid noisy/unintended changes.
Benefits
Team Collaboration
By logically dividing a dashboard across files, Teams can simultaneously work on sub-components of the dashboard.
Reusable Components
Scripts, datamodels, widgets and entire dashboards can be written once and then reused across dashboards.
Dashboard Tracking, Versioning, Branching
As AMI files are managed by source control, they can be used to label versions of a dashboard, compare versions and manage branching.
Merging Independent Projects
Existing dashboards can be incorporated into new dashboards making it easy to build super-dashboards cross-incorporating functionality
Enterprise Deployment Strategy
Treat AMI files just like any other resources that are managed through deployment strategies, such as uDeploy, TeamCity, etc.
Dashboard Extension
Extend existing dashboards for regional/business line specific usage without needing to maintain multiple near duplicate dashboards.
Full Backwards Compatibility
File
Loads existing dashboards and automatically converts to the new format. Note: files are still json with the same general structure, just less clutter/redundancy.
Usage
Users & dashboard developers can continue to develop/maintain dashboards without change. Changes are purely additive, existing functionality has not been changed nor removed.
Split Dashboards
Split existing dashboards into separate files for better SCM management.
Combine Dashboards
Utilize multiple existing dashboards to create a single super-dashboard.
Key Concepts
Dashboards vs. Layout
Prior to Source Control Management (SCM), a Dashboard was backed by a single Layout file, so the terms were interchangeable. With SCM, a Dashboard can be an amalgamation of multiple Layout files so the distinction matters:
- Layout: an individual .ami file which contains a set of source definitions such as Panels, Datamodels, Relationships, AmiScript, etc.
- Dashboard (Root Layout): the .ami file that is directly opened (ex: File > Absolute File - Open) is considered a Dashboard, or more specifically the Root Layout