From bacf0dc1e4d47e9fa1f7f4a837e8ed277f74a495 Mon Sep 17 00:00:00 2001 From: TracyRagan Date: Sun, 28 Jun 2020 15:33:34 -0600 Subject: [PATCH] updates to pipelines, custom types --- .../Customizations/2 Define Your Actions.md | 16 +- .../2 Define Your Functions and Procedures.md | 212 ++++++------------ .../userguide/Customizations/CustomTypes.md | 44 ++++ .../First Steps/2 Define Repositories.md | 7 - .../First Steps/2 Define Your Credentials.md | 8 +- .../2 Defining Applications.md | 48 ++-- .../2 Define Components.md | 29 +-- .../concepts/3 Executing Deployments.md | 25 ++- .../userguide/concepts/LifecycleSubDomains.md | 39 ++++ .../integrations/Ansible Playbook.md | 22 +- content/en/userguide/integrations/Git.md | 9 - content/en/userguide/integrations/GitHub.md | 100 +++------ content/en/userguide/integrations/Helm.md | 62 +++-- .../integrations/Intro to Integrations.md | 11 +- .../Jira, Bugzilla and Git Issues.md | 11 +- .../en/userguide/integrations/Salesforce.md | 12 +- content/en/userguide/integrations/Tomcat.md | 14 +- .../pipeline/2 Defining Your Pipeline.md | 30 --- content/en/userguide/pipeline/_index.md | 7 - .../userguide/profeatures/2 Data Sources.md | 31 ++- .../profeatures/5 Application Releases.md | 57 ++--- .../profeatures/5 Change Requests.md | 16 -- .../en/userguide/reusable/ChangeRequest.md | 10 + .../en/userguide/reusable/LDAP-DataSource.md | 3 +- .../en/userguide/reusable/Model Success.md | 2 +- .../2 Define Your Build Engines.new} | 0 .../userguide/{pipeline => save}/BuildJobs.md | 0 27 files changed, 366 insertions(+), 459 deletions(-) create mode 100644 content/en/userguide/Customizations/CustomTypes.md create mode 100644 content/en/userguide/concepts/LifecycleSubDomains.md delete mode 100644 content/en/userguide/integrations/Git.md delete mode 100644 content/en/userguide/pipeline/2 Defining Your Pipeline.md delete mode 100644 content/en/userguide/pipeline/_index.md delete mode 100644 content/en/userguide/profeatures/5 Change Requests.md create mode 100644 content/en/userguide/reusable/ChangeRequest.md rename content/en/userguide/{pipeline/2 Define Your Build Engines.md => save/2 Define Your Build Engines.new} (100%) rename content/en/userguide/{pipeline => save}/BuildJobs.md (100%) diff --git a/content/en/userguide/Customizations/2 Define Your Actions.md b/content/en/userguide/Customizations/2 Define Your Actions.md index 8b6d9ee9..382d24a4 100644 --- a/content/en/userguide/Customizations/2 Define Your Actions.md +++ b/content/en/userguide/Customizations/2 Define Your Actions.md @@ -81,6 +81,7 @@ The Dashboard view displays all information related to a specific _Action_. | **Owner** | The _User_ or _Group_ name of the _Action's_ owner. The default owner is the _User_ who created the _Action_. | | **Created** | An auto generated date when the _Action_ was created (read-only). | | **Modified** | An auto generated date when the _Action_ was last modified (read-only). | +|**Display Name**| You can use this field to create a more user friendly name for your _Action_| ### Access @@ -98,11 +99,20 @@ NOTE: **DeployHub Team** has only two Groups, _Administrators_ and _Users_. If y ### Blueprint Section -The logic of an _Action_ is defined using a graphical drag and drop blueprint designer. A tree view on the right shows all the _Functions_ and _Procedures_ organized by categories that can be include in the _Action's_ logic. You can use the built-in activities for defining the logical steps of the _Action_ or you can create new _Procedures_ or _Functions_ and have them available as activities to use. See [_Functions_ and _Procedures_](/userguide/customizations/2-define-your-functions-and-procedures/) for more information. +The logic of an _Action_ is defined using a graphical drag and drop blueprint designer. A tree view on the right shows all the _Functions_ and _Procedures_ organized by categories that can be include in the _Action's_ logic. You can use the built-in activities for defining the logical steps of the _Action_ or you can create new _Procedures_ or _Functions_ and have them available as activities to use. See [_Functions_ and _Procedures_](/userguide/customizations/2-define-your-functions-and-procedures/) for more information. -The blueprint designer contains all activities that make up the _Actions_ logical processing steps, linked together in the order they are to be executed. Each step in the process has anchors where connections can be made. When you drag a item onto the designer, a blue input anchor is displayed the top of the items "box." You will see a green anchor at the bottom representing output. In this way you can create connections between the processes. +The blueprint designer contains all activities that make up the _Actions_ logical processing steps, linked together in the order they are to be executed. Each step in the process has anchors where connections can be made. When you drag a item onto the designer, a blue input anchor is displayed at the top of the items "box." You will see a green anchor at the bottom representing output. In this way you can create connections between the processes. -Click on one of the Categories in the list to see the available _Functions_ or _Procedures_. Expand a Category and then select the desired Activity to drag and drop it into the _Action_ blueprint area. It appears as a box containing the name of the _Function_ or _Procedure_. It automatically links to the nearest "box" with a output anchor. An editor box opens automatically to set any input values required. If the dropped item is a _Function,_ then an additional _Result_ field is presented. This needs to be the name of a _Variable_ that receives the result of the _Function_. +Click on one of the Categories in the list to see the available _Functions_ or _Procedures_. Expand a Category and then select the desired Activity to drag and drop it into the _Action_ blueprint area. It appears as a box containing the name of the _Function_ or _Procedure_. It automatically links to the nearest "box" with a output anchor. + +#### The _Function_ or _Procedure_ Parameter Dialog Box + +The Parameter Dialog Box displays the options defined when the _Function_ or _Procedure_ was created using the Input Parameters Section from the _Functions_ and _Procedures_ Dashboard. When you add a new _Function_ or _Procedure_ to your _Action_ blueprint designer, the Parameter Dialog Box will automatically display. If you are working on an existing _Action_ and want to view the parameters, a right click will display: + +- View Detials - opens the Parameter Dialog Box +- Got to the Procedure - takes you to the Dashboard of the _Function_ or _Procedure_. Your work will be saved automatically before navigating to the _Functions_ and _Procedures_ Dashboard. +- Delete this Activity - deletes the _Function_ or _Procedure_ from the blueprint designer. +An editor box opens automatically to set any input values required. If the dropped item is a _Function,_ then an additional _Result_ field is presented. This needs to be the name of a _Variable_ that receives the result of the _Function_. You can connect items in any order you require. To do this, left-click and hold down the button on one of the output anchors, then drag the resulting line onto another input anchor. This connects the items together and determines the order for processing the steps. The lines connecting items can be deleted by right clicking on the connector line and selecting "Delete this Connector". diff --git a/content/en/userguide/Customizations/2 Define Your Functions and Procedures.md b/content/en/userguide/Customizations/2 Define Your Functions and Procedures.md index bd146edb..4627ea1e 100644 --- a/content/en/userguide/Customizations/2 Define Your Functions and Procedures.md +++ b/content/en/userguide/Customizations/2 Define Your Functions and Procedures.md @@ -3,7 +3,7 @@ title: "Procedures and Functions" linkTitle: "Procedures and Functions" weight: 34 description: > - Customizing your Deployments with Procedures and Functions. + Customizing your Deployment _Actions_ with _Functions_ and _Procedures_. --- ## Functions and Procedures @@ -11,26 +11,16 @@ _Functions_ and _Procedures_ are the steps that make up an _Action_. If you have _Functions_ and _Procedures_ are used by _Actions_ to define custom installation logic of a _Component_ or perform any type of Pre or Post Action. Using _Actions_, _Functions_ and _Procedures_ allows you to be as creative as needed to meet the unique needs of your implementation. -The difference between _Procedures_ and _Functions_ is a _Procedures_ execute a process but does not return a value. A _Function_ returns a value. _Functions_ and _Procedures_ can be: +The difference between _Functions_ and _Procedures_ is a _Procedure_ execute a process but does not return a value. A _Function_ returns a value. DeployHub provides a Dashboard for customizing your _Functions_ and _Procedures_ including the creation of Parameters, and a Parameters Dialog box that is displayed at the _Action_ level. The Parameters Dialog Box enables other _Users_ to utilize your custom process, with an easy way to understand what Parameter options are available. In this way, you are able to create custom _Functions_ and _Procedures_ and share them across teams. The associated Parameters Dialog Box simplifies the use of your custom process. -_Procedure_ Types +_Functions_ and _Procedures_ can be: -| Procedure | Description | -| --- | --- | -| _**DMScript Procedure in Repository**_ | A _Procedure_ is written in DMScript and stored in a file located in an external _Repository._ | -| _**DMScript Procedure in Database**_ | A _Procedure_ is written in DMScript and stored in the DeployHub Database (a "Stored Procedure"). | -| _**Procedure Provided by Local External Script or Program**_ | A _Procedure_ is written in any Scripting Language that can be executed by the operating system on which the DeployHub Deployment Engine is installed. Executes locally to the Deployment Engine. | -| _**Procedure Provided by Remote External Script or Program**_ | A _Procedure_ is written in any Scripting Language that can be executed by the target _Endpoint's_ operating system. Executes on the target _Endpoint._ By Checking the "Copy to Remote" flag, the script can be held locally to the Deployment Engine and copied to the target _Endpoint_ at the point of execution. | - -_Function_ Types -| Function | Description | +| _Function_ or _Procedure_ Type | Description | | --- | --- | -| _**DMScript Function in Repository**_ | A _Function_ is written in DMScript and stored in a file located in an external _Repository._ | -| _**DMScript Function in Database**_ | A _Function_ is written in DMScript and stored in the DeployHub Database (a "Stored Procedure"). | -| _**Function Provided by Local External Script or Program**_ | A _Function_ is written in any Scripting Language that can be executed by the operating system on which the DeployHub Deployment Engine is installed. Executes locally to the Deployment Engine. | -| _**Function Provided by Remote External Script or Program**_ | A _Function_ is written in any Scripting Language that can be executed by the target _Endpoint's_ operating system. Executes on the target _Endpoint._ By Checking the "Copy to Remote" flag, the script can be held locally to the Deployment Engine and copied to the target _Endpoint_ at the point of execution. | - +| **DMScript in Database** | A _Function_ or _Procedure_ is written in DMScript and stored in the DeployHub Database (a "Stored Procedure"). | +| **Local Script** | A _Function_ or _Procedure_ is written in any Scripting Language that can be executed by the operating system on which the DeployHub Deployment Engine is installed. Executes locally to the Deployment Engine. | +| **Endpoint Script** | A _Function_ or _Procedure_ is written in any Scripting Language that can be executed by the target _Endpoint's_ operating system. Executes on the target _Endpoint._ By Checking the "Copy to Remote" flag, the script can be held locally to the Deployment Engine and copied to the target _Endpoint_ at the point of execution. | ## The _Functions_ and _Procedures_ List View for Adding or Deleting @@ -44,133 +34,104 @@ The _Function_ or _Procedure_ List View has the following Tabs. | Tab | Description | | --- | --- | -|Refresh | Refreshes the browser. | -| Add Function | Allows you to Add a new _Function_. | -| Add Procedure | Allows you to Add a new _Procedure_.| -| Export | Allows you to Export an existing _Function_ or _Procedure_. Used to transfer _Functions_ and _Procedures_ between DeployHub installations, and allows you to check them into a source repository. -| Import | Takes a previously exported _Function_ or _Procedure_ and re-imports it. Will maintain the original _Function_ or _Procedure_ name regardless of the name of the import file (.re). To change the Name of the _Function_ or _Procedure_, update the "action name="[new name]" inside the .re file that was exported. Duplicate names are allowed as long as they are defined using a different _Domain_.| -| Delete | Deletes the selected item. | +|**Refresh** | Refreshes the browser. | +| **Add Procedure** | Allows you to Add a new _Procedure_. | +| **Add Function** | Allows you to Add a new _Function_ with the types: | +| **Delete** | Deletes the selected item. | +| **Export** | Allows you to Export an existing _Function_ or _Procedure_. Used to transfer _Functions_ and _Procedures_ between DeployHub installations, and allows you to check them into a source repository.| +| **Import** | Takes a previously exported _Function_ or _Procedure_ and re-imports it. Will maintain the original _Function_ or _Procedure_ name regardless of the name of the import file (.re). To change the Name of the _Function_ or _Procedure_, update the "action name="[new name]" inside the .re file that was exported. Duplicate names are allowed as long as they are defined using a different _Domain_.| From the _Functions_ and _Procedures_ List View, double click on the _Functions_ or _Procedures_ to view to see all Details. - ## Using the _Function_ or _Procedure_ Dashboard for Viewing and Editing -The Dashboard view displays all information related to a specific _Function_ or _Procedure_. -Selecting the _Procedure/Function_ kind will show other fields relevant to that particular kind (for example "Copy to Remote" will only appear for kind "Remote External Script or Program". Fill in the fields and then click OK to create the new _Procedure/Function_. +The Dashboard view displays all information related to a specific _Function_ or _Procedure_. The following details are common to all Types. | Details | Description | | --- | --- | -| **Name** | A unique Name that identifies the _Function_ or _Procedure_ | -| **Summary** | A brief description of what the _Function_ or _Procedure_ does. | -| **Category** | Categories are used to arrange _Function_ or _Procedure_ in an orderly manner. Assigning a Category to an _Function_ or _Procedure_ allows lists of Categories to be used throughout DeployHub. Clicking on an individual Category expands the list and shows all _Function_ or _Procedure_ that belong to that Category. You can add a new Category by simply adding it to the list using the entry field. Pre-defined Categories include:
  • Build - _Actions_, _Functions_ and _Procedures_ for calling ANT (SalesForce integration).
  • Database - _Actions_, _Functions_ and _Procedures_ for database updates.
  • Deploy-_Actions_, _Functions_ and _Procedures_ for Deployments.
  • Dropzone- _Actions_, _Functions_ and _Procedures_ for interacting with the Dropzone.
  • File Logic-_Actions_, _Functions_ and _Procedures_ related to File manipulation.
  • Flow Logic-_Actions_, _Functions_ and _Procedures_ for if then else in DMScrit.
  • Loops-_Actions_, _Functions_ and _Procedures_for file looping.
  • General-Non-categorized Objects (default).
  • WebLogic-_Actions_, _Functions_ and _Procedures_ for deploying to WebLogic.
  • WebSphere-_Actions_, _Functions_ and _Procedures_ for deploying to WebSphere.
  • Windows-_Actions, Functions_ and _Procedures_ used for Windows deployments.
    • | -| **Owner Type** | User or Group | -| **Owner** | The _User_ or _Group_ name of the _Function_ or _Procedure's_ owner. The default owner is the _User_ who created the _Function_ or _Procedure_. | -| **Created** | An auto generated date when the _Function_ or _Procedure_ was created (read-only). | -| **Modified** | An auto generated date when the _Function_ or _Procedure_ was last modified (read-only). | -| **Description** | A more detailed Description of the _Function_ or _Procedure_. -|**Kind**| Select _Function_ or _Procedure_. Selecting the _Procedure/Function_ kind will show other fields relevant to that particular kind (for example "Copy to Remote" will only appear for kind "Remote External Script or Program". Fill in the fields and then click OK to create the new _Procedure/Function_.| +|**Full Domain** | The fully qualified _Domain_ to which the _Function_ or _Procedure_ belongs. | +|**Name** | A unique Name that identifies the _Function_ or _Procedure_ | +|**Summary** | A brief description of what the _Function_ or _Procedure_ does. | +|**Category** | Categories are used to arrange _Function_ or _Procedure_ in an orderly manner. Assigning a Category to an _Function_ or _Procedure_ allows lists of Categories to be used throughout DeployHub. Clicking on an individual Category expands the list and shows all _Function_ or _Procedure_ that belong to that Category. You can add a new Category by simply adding it to the list using the entry field. Pre-defined Categories include:
  • Build - _Actions_, _Functions_ and _Procedures_ for calling ANT (SalesForce integration).
  • Database - _Actions_, _Functions_ and _Procedures_ for database updates.
  • Deploy-_Actions_, _Functions_ and _Procedures_ for Deployments.
  • Dropzone- _Actions_, _Functions_ and _Procedures_ for interacting with the Dropzone.
  • File Logic-_Actions_, _Functions_ and _Procedures_ related to File manipulation.
  • Flow Logic-_Actions_, _Functions_ and _Procedures_ for if then else in DMScrit.
  • Loops-_Actions_, _Functions_ and _Procedures_for file looping.
  • General-Non-categorized Objects (default).
  • WebLogic-_Actions_, _Functions_ and _Procedures_ for deploying to WebLogic.
  • WebSphere-_Actions_, _Functions_ and _Procedures_ for deploying to WebSphere.
  • Windows-_Actions, Functions_ and _Procedures_ used for Windows deployments.
    • | +|**Owner Type** | User or Group | +|**Owner** | The _User_ or _Group_ name of the _Function_ or _Procedure's_ owner. The default owner is the _User_ who created the _Function_ or _Procedure_. | +|**Created** | An auto generated date when the _Function_ or _Procedure_ was created (read-only). | +|**Modified** | An auto generated date when the _Function_ or _Procedure_ was last modified (read-only). | +|**Object** | Displays if the item is _Function_ or _Procedure_. +|**Type**| Displays the kind of the _Function_ or _Procedure_ created when added.| |**Display Name**| An alternative Name if required. If not used defaults to the "Name".| -| _**Filepath**_ | The filepath to the script to be executed, which includes the name of the script. This appears for all but the "DMScript Procedure in Database" Kind of _Procedure_ or _Function_. | -| _**Allocate Terminal**_ | If checked, this sets up a pseudo-terminal. This is for Unix/Linux targets only when operating over SFTP transfer protocol. It controls the behavior of executed programs if they operate differently with or without an allocated terminal. Note that any program running with this flag set and which calls _isatty_ will receive a return code of _true_. | -| _**Copy to Remote**_ | A checkbox that causes DeployHub to copy the procedure script from the directory indicated by the filepath field on the localhost machine to the target machine. The procedure is then executed there. In Windows, it is placed into c:\Windows\System32. On Linux/Unix, it is placed into /tmp. This only appears for _Procedures_/_Functions_ that are of the Kind 'Procedure/Function provided by remote external script or program'. | -| _**Result is Expr**_ | Available only for _Functions._ If this box is checked then the return value from the function is interpreted as DMScript.Thus, if the _Function_ returns this as its standard output: -set a = {"x" => "1", "y" => "2"}; If "result is expr" is checked, an array is created called "a" with two elements - key "x" will be value "1" and key "y" will be value "2". This is used in various _Functions_. For example, the "listservices" _Function_ which lists the services on a Windows server returns the list into an array using this mechanism. | -### Access +**Additional Details for _Local_ Scripts** -The Access Section allows _Users_ within designated _Groups_ to update the _Function_ or _Procedure_ in various ways. To add a _Group_ to one of the access lists, drag and drop the _Group_ from the Available Groups list onto desired access list. All _Users_ who belong to a _Group_ that appear in one of the Access lists will be granted access to the _Function_ or _Procedure_ in the following ways: +This type of _Function_ or _Procedure_ runs on the deployment engine and requires these additional details. -| Access | Description | +| Details | Description | | --- | --- | -|**View**| Allows _Users_ to see the _Function_ or _Procedure_. If the _User_ does not belong to a _Group_ in the View Access list, the _Function_ or _Procedure_ will not appear in the List View. | -|**Change**| Allows _User_ to change the _Function_ or _Procedure_ characteristics i.e. Name, Summary, etc. | -|**Execute**| Allows _Users_ to execute this _Function_ or _Procedure_. | +| **Filepath** | The filepath to the script to be executed, which includes the name of the script. | +|**Command Line Interpreter**| Your _Function_ or _Procedure_ will be written using a particular language such as Python. This field in the fully qualified path and name of your interpreter. DeployHub will need this to execute your process.| +|**Result is Expr** | Result is Expression is used for return values for _Functions_ only. This will not be displayed for _Procedures_ as they do not return a value. If this box is checked, the return value from the _Function_ is interpreted as DMScript. For example, the "listservices" _Function_ which returns a list of services on a Windows _Endpoint_ returns the list into an array using this option. | -NOTE: **DeployHub Team** has only two Groups, _Administrators_ and _Users_. If you need more granularity in your UserGroups, you will need to upgrade to **DeployHub Pro.** +**Additional Details for _Endpoint_ Scripts** -{{% include "userguide/reusable/AuditTrail.md" %}} - -## Input Parameters – External Procedure/Function - -A list of arguments can be made available for the _Procedure/Function_. To create a new Argument, go to the Flows menu, select a _Procedure/Function_ in the tree structure, and click the Args tab. Select the Plus (+) icon to add a new argument to the table, or click the pencil icon to edit an Argument selected in the table. The content and layout of the Args Tab will differ depending on the type of _Procedure/Function_. +This type of _Function_ or _Procedure_ runs on the _Endpoint_ and requires these additional details. -## Type: External Procedure/Function - -There are two sections to the Args tab for External _Procedures_ or _Functions_ (either local or remote). These sections allow you to construct a command line from the arguments passed to the _Procedure/Function_. The section titled 'Inputs to this Function/Procedure' contains the following fields: - -| Field | Description | +| Details | Description | | --- | --- | -| _**Name**_ | Name of the Argument. The Name must start with a letter and must only include A-Z, a-z, 0-9 and \_ (underscore). No spaces or dashes are allowed in the name. | -| _**Type**_ | Values are Entry or Checkbox. This determines how the "input" to the _Procedure_ or _Function_ is rendered when it is dropped into the _Action Editor_. | -| _**Present**_ | Type: EntryThe text that will be prepended to the value should the argument be provided. For example, for a "filename" argument the _Present_ flag could be set to –f. If filename is provided then the argument will become –f "". - -Type: CheckboxThe text that will appear if the checkbox is selected. For example, if _Present_ is set to –checked then the argument will become –checked should the checkbox be checked. | -| _**Missing**_ | Type: EntryThe value that will be inserted should the argument not be provided. Only used if "Required" (see below) is false. If the optional argument is not provided then the _Missing_ text is substituted. For example, for a "filename" argument the _Missing_ flag could be set to –nofile. If no filename is provided then the argument will become –nofile. - -Type: CheckboxThe text that will appear if the checkbox is not selected. For example, if Missing is set to –notchecked then the argument will become ‑notchecked should the checkbox be unchecked. | -| _**Preserve With (Pad)**_ | _Preserve With "" When Not Present_ ensures that the argument occupies its positional parameter regardless of whether it is a null-length string or not. For example, if the command line ismyscript ARG1 ARG2 ARG3if ARG2 is a null-length string then myscript would be called with: myscript ARG1 ARG3Padding (or preserving) will mean the script is invoked like this: myscript ARG1 **""** ARG3This feature is useful if the script always requires the same parameters to be in the same position on the command line. | -| _**Required**_ | Indicates the argument is required for the _Procedure/Function_. This is used when dropping the _Procedure/Function_ into the Action Editor. Any Argument marked as being "Required" is highlighted and cannot be left blank. | - -The section titled 'Additional command line switches for program below' allows for the creation of "fixed" command line switches or other attributes that you wish to have present on the generated command line. These can be created by clicking on the plus sign (+) icon and adding text. - -Each "Additional Command Line Switch" can include variables and these will be expanded when the command line is constructed and executed. These variables can be attributes stored against a DeployHub Object (such as _Endpoint, Environment, Application,_ or _Component_) or can be _Global Variables_ that are set by _Additional Parameters_ to the invoking Task. See Chapter 1 (Domains) for more information on adding _Additional Parameters_ to _Tasks_. - -Each "Additional Command Line Switch" will be "padded" (surrounded by implicit quotes) and will be treated as a single argument when the command line is constructed. If you want to have separate flags and variables (for example –homedir $SERVDIR (where SERVDIR is an attribute held against the Target _Endpoint_) then you will need to create two "Additional Command Line Switches" – one for –homedir and one for $SERVDIR. +| **Filepath** | The filepath to the script to be executed, which includes the name of the script. | +|**Command Line Interpreter**| Your _Function_ or _Procedure_ will be written using a particular language such as Python. This field in the fully qualified path and name of your interpreter. DeployHub will need this to execute your process.| +| **Allocate Terminal** | If checked, this sets up a pseudo-terminal. This is for Unix/Linux targets only when operating over SFTP transfer protocol. It controls the behavior of executed programs if they operate differently with or without an allocated terminal. Note that any program running with this flag set and which calls _isatty_ will receive a return code of _true_. | +|**Result is Expr** | Result is Expression is used for return values for _Functions._ If this box is checked, the return value from the _Function_ is interpreted as DMScript. For example, the "listservices" _Function_ which returns a list of services on a Windows _Endpoint_ returns the list into an array using this option. | +|**Copy to Remote** | A checkbox that causes DeployHub to copy the script from the directory indicated by the filepath field on the deployment engine to the target _Endpoint_. The script is then executed there. | -All the input parameters and the Additional Command Line Switches will appear above the resulting command line in dotted boxes. To construct the command line, simply drag and drop the boxes in the order required to build the command line. - -## Type: DMScript - -There is only a single section to the Args tab for DMScript _Procedures_ or _Functions_ (either _in Repository_ or _in Database_). +### Access -The section titled 'Inputs to this Function/Procedure' contains the following fields: +The Access Section allows _Users_ within designated _Groups_ to update the _Function_ or _Procedure_ in various ways. To add a _Group_ to one of the access lists, drag and drop the _Group_ from the Available Groups list onto desired access list. All _Users_ who belong to a _Group_ that appear in one of the Access lists will be granted access to the _Function_ or _Procedure_ in the following ways: -| Field | Description | +| Access | Description | | --- | --- | -| _**Name**_ | Name of the Argument. The Name must start with a letter and must only include A-Z, a-z, 0-9 and \_ (underscore). No spaces or dashes are allowed in the name. | -| _**Type**_ | Values are Entry or Checkbox. This determines how the "input" to the _Procedure_ or _Function_ is rendered when it is dropped into the _Action Editor_. | -| _**Required**_ | Indicates the argument is required for the Procedure. This is used when dropping the Procedure/Function into the Action Editor. Any Argument marked as being "Required" is highlighted and cannot be left blank. | - -Entered Parameters will be accessible as variables within the DMScript Procedure/Function. Checkbox values are passed as true (1) if the checkbox is selected, false (0) otherwise. You can therefore use DMScript constructs like this: +|**View**| Allows _Users_ to see the _Function_ or _Procedure_. If the _User_ does not belong to a _Group_ in the View Access list, the _Function_ or _Procedure_ will not appear in the List View. | +|**Change**| Allows _User_ to change the _Function_ or _Procedure_ characteristics i.e. Name, Summary, etc. | +|**Execute**| Allows _Users_ to execute this _Function_ or _Procedure_. | -```bash -if ($myval) { +{{% include "userguide/reusable/AuditTrail.md" %}} -// myval checkbox is checked +### Input Parameters – and Command Line Switches for your Custom _Function_ or _Procedures_ -} else { +When you create your _Function_ or _Procedure_ it will most likely need parameters. This section allows you to define the format of the parameters and display them in the _Action_ blueprint designer. When your _Function_ or _Procedure_ is added to the _Action_ blueprint designer, a Parameter Dialog Box will be automatically displayed prompting the user to enter the required values. A right mouse click on the same will open the Parameter Dialog Box. The Input Parameters, Command Line Switches and the Command Line Section work together to define how the command line call will be formatted. You will establish how your user will enter parameter values when they use your custom _Function_ or _Procedure_ through the use of the Parameter Dialog Box. For _Functions_ and _Procedures_ that are of the Type "DM Script in Database", you will not see Command Line Switches Section or a Command Line Section. Instead you will be provided with an embedded editor for creating the DMScript that will be saved in the Database. -// myval checkbox is NOT checked +- The Input Parameters Section defines how the dialog box is layed out and how the flags will be passed to the command line. +- The Command Line Switches Section provides a table of parameter switches that can be used to construct the command line call. +- The Command Line Section builds out what your command line call will look like using drog and drop of the Input Parameters and Switches. -} -``` +**Input Parameters Section** -To see if the checkbox named "myval" is checked or not +This section has two purposes. First to define the fields that will be presented on the Parameters Dialog box as a checkbox or entry field. Secondly, it defines the parameters being passed to the command line by the _Function_ or _Procedure_. -{{% include "userguide/reusable/AuditTrail.md" %}} +A list of parameters can be made available for the user of your _Function_ or _Procedure_ from the _Actions_ blueprint designer. To create a new parameter, Use the +Add option. A new row in the table will be made available where you can then define the following parameter attributes: -## Body Section +|Attribute| Description| +|---|---| +|**Name** | The name of the input parameter. It can only have the characters A-Z, 0-8, and "_". | +|**Type**| This defines if the input parameter can be entered as text, or as a checkbox. This field will be displayed on the dialog box used to edit the values for the Procedure or Function on the _Action_ blueprint designer.| +|**Format**| This field defines what your Parameters Dialog Box will look like. | +|**Missing**|This field provides a default if the above Format value is null. Like the Format value, it uses Entry and Checkbox types. +|**Padding**| This field is used for positional command line parameters where you need to provide quote, space, quote (" ") for a positional parameter that is not entered by the user. This prevents the command line from throwing and error. +|**Required**|Indicates the argument is required for the Procedure/Function. Any parameter marked as being "Required" is highlighted and cannot be left blank. +|**Pos**| This is used only when calling the _Function_ or _Procedure_ from DMScript. The Position orders the parameters when making the call in DMScript. -For Procedures/Functions defined as being "DMScript in Database" an additional "Body" tab is presented which allows the "stored" DMScript to be viewed and edited. Clicking on the "Body" tab will show the DMScript associated with the Procedure/Function. This is presented with syntax highlighting (it is optional and is set on by default). +**Command Line Switches** -```bash -action name { +The Section allows for the creation of "fixed" command line switches or other attributes that you wish to have present on the generated Command Line. These can be created by clicking on the plus +Add option to add a new switch. You must use Save to commit the new row to the table. When you add Parameters and Switches, they are placed in a "pallet" above the Command Line Section. To remove or update an item, check the item and use Delete or Edit options. -} -``` +Each "Command Line Switch" can include variables which will be expanded when the Command Line is constructed and executed. These variables can be attributes stored against a DeployHub Object (such as _Endpoint, Environment, Application,_ or _Component_) or can be Global Variables. -or +**Command Line** -```bash -function name(arg1,arg2) { +You can drag and drop the items from the "pallet" of Switches in the correct order on your Command Line. The result displays how the Command Line has been constructed. -} -``` +**DMScript in Database Editor** -NOTE: The DMScript "header" for the Procedure or Function is implicit from the Args tab and should not be entered. This means you should just edit the "Body" of the Script and not attempt to add either. - -To Edit the DMScript body, click on the pencil icon in the top-right of the Body Tab. You'll see an edit area (into which text can be typed) and a menu bar with icons and drop-downs: +The embedded editor includes: - The Floppy Disk Icon is the "Save" button. This parses the DMScript for errors and, if none are found, saves the DMScript. If there any syntax errors, they are highlighted in the body of the text. - The Binoculars Icon is the "Search" button. Clicking this icon opens a search/replace dialog. @@ -181,37 +142,6 @@ To Edit the DMScript body, click on the pencil icon in the top-right of the Body - The Eraser Icon resets the syntax highlighting and causes the editor to re-parse and re-highlight the entered text. - The Paragraph Marker Icon switches on word wrapping. -Enter or change the DMScript body in the main editor window. Double clicking on an opening or closing brace will highlight both the selected brace and its matching brace. Clicking OK will check the DMScript for syntax errors and – if none are found – will close the window. If any issues are found, the cursor is placed onto the line in error and the error message is shown on the line under the editor window. It is not possible to save DMScript with such syntax errors. - -## General Tab - -The General tab is where the basic information about the _Function_ or _Procedure_ is defined. This information includes: - -| Field | Description | -| --- | --- | -| _**Name**_ | Name of the _Function_/_Procedure._ This cannot be the same as a reserved word within DMScript (see the DMScript chapter), as it will cause a syntax error when executed. | -| _**Summary**_ | A short description of the _Function_/_Procedure._ | -| _**Category**_ | The category in which the _Function/Procedure_ can be found under the Activities pane on the Action Editor. | -| _**Owner Type**_ | The default owner is the _User_ who created the _Function/Procedure_. When editing this field, the _Owner Type_ field is available which includes _Owner_ and _Group_ as choices. Selecting one of these causes the Owner field to display either _Users_ or _Groups_ to choose from. | -| _**Created**_ | The date and time the _Function_/_Procedure_ was created. Read Only. | -| _**Modified**_ | The date and time that the _Function_/_Procedure_ was last modified. Read Only. | -| _**Description**_ | A brief description of the Procedure/Function. | -| _**Kind**_ | | -| _**Display Name**_ | The name that appears on the icon that represents the _Procedure_/_Function_ within a Workflow. Defaults to the value of the _Name_ field if not supplied. | -| _**Filepath**_ | The filepath to the script to be executed, which includes the name of the script. This appears for all but the "DMScript Procedure in Database" Kind of _Procedure_/_Function_. | -| _**Allocate Terminal**_ | If checked, this sets up a pseudo-terminal. This is for Unix/Linux targets only when operating over SFTP transfer protocol. It controls the behavior of executed programs if they operate differently with or without an allocated terminal. Note that any program running with this flag set and which calls _isatty_ will receive a return code of _true_. | -| _**Copy to Remote**_ | A checkbox that causes DeployHub to copy the procedure script from the directory indicated by the filepath field on the localhost machine to the target machine. The procedure is then executed there. In Windows, it is placed into c:\Windows\System32. On Linux/Unix, it is placed into /tmp. This only appears for _Procedures_/_Functions_ that are of the Kind 'Procedure/Function provided by remote external script or program'. | -| _**Result is Expr**_ | Available only for _Functions._ If this box is checked then the return value from the function is interpreted as DMScript. - Thus, if the _Function_ returns this as its standard output: - -```set a = {"x" => "1", "y" => "2"};``` - - If "result is expr" is checked, an array is created called "a" with two elements - key "x" will be value "1" and key "y" will be value "2". - - This is used in various _Functions_. For example, the "listservices" _Function_ which lists the services on a Windows server returns the list into an array using this mechanism. | - -To delete a _Procedure/Function_, right click on it in the tree structure and select "Delete this Procedure". - -## Archiving +## Archiving _Functions_ and _Procedures_ -Any time a _Procedure_ or _Function_ is changed, an archived version is saved within DeployHub. In the tree structure beneath the Function or Procedure, and within the Domain, there will be a copy of the Function/Procedure with all Access removed, using the original name followed by '_archived'. Every time the Function/Procedure is changed, another one will appear with the name followed by an incremented number ('_archived\_1', '_archived\_2', etc.). +Automatic archives are created for all _Functions_ or _Procedures_ that are in use by an _Action_. If you change a _Function_ or _Procedure_ the archive will be displayed in the List View for reference. Every time the _Function_ or _Procedure_ is changed, it will be archived in the List View and appear with the name followed by an incremented number ('_archived\_1', '_archived\_2', etc.). diff --git a/content/en/userguide/Customizations/CustomTypes.md b/content/en/userguide/Customizations/CustomTypes.md new file mode 100644 index 00000000..76b66dad --- /dev/null +++ b/content/en/userguide/Customizations/CustomTypes.md @@ -0,0 +1,44 @@ +--- +title: "Custom Types" +linkTitle: "Custom Types" +weight: 90 +description: > + Adding Custom Types for _Endpoints_. +--- + +## Intro to _Custom Types_ + +_Custom Types_ or found on the _Endpoint_ Dashboard and the _Component_ Dashboard and are used to map a _Component_ to it's appropriate _Endpoint_. For example, a default _Endpoint Type_ is "Application Server." This maps to a _Component_ defined as an "Application Server." This mapping allows _Endpoints_ in an _Environment_ to be dynamically assigned _Components_ based the _Endpoint Type_. + +_Components_ map to a single _Endpoint_, but an _Endpoint_ can map to multiple types of _Components_. For example, your _Endpoint_ could serve as both your Application Server and Database Server. + +You can create your own _Endpoint Types_ for defining this mapping. + +## Using the _Customize Type_ List View for Adding or Deleting + +You will find _Customize Types_ from the left hand side of the DeployHub main panel. Selecting _Customize Types_ will take you to a list of all _Custom Types_ which you have access to. You can also use the Filter bar, represented by a funnel icon, to reorder your _Custom Types__ List View based on Type and _Domain_. + +The _Custom Type_ List View has the following Tabs. + +| Tab | Description | +| --- | --- | +|**Refresh** | Refreshes the browser. | +|**Add** | Allows you to Add a new _Custom Type_. | +|**Delete** | Deletes the selected item. | + +From the _Custom Type_ List View, double click on the _Custom Type_ which you would like to view to see all Details. + +## Using the _Custom Type_ Dashboard for Viewing and Editing + +The _Custom Type_ Dashboard view displays all information related to a specific _Custom Type_. + +### _Custom Type_ Details + +The following details are common to all _Custom Type_: + +| Field | Description | +| --- | --- | +| **Full Domain** | The fully qualified name of the _Domain_ to which the _Custom Type_ was defined. | +|**Name**| The name of your _Custom Type_.| +| **Database Roll-forward/Rollback** | Select this checkbox if your _Custom Type_ uses a database. | + diff --git a/content/en/userguide/First Steps/2 Define Repositories.md b/content/en/userguide/First Steps/2 Define Repositories.md index 2d8f41e1..3d59fcc1 100644 --- a/content/en/userguide/First Steps/2 Define Repositories.md +++ b/content/en/userguide/First Steps/2 Define Repositories.md @@ -39,14 +39,11 @@ The Dashboard view displays all information related to a specific _Repository_ T - HTTP - File System (included as a default with override and append options enabled) -- Git - OpenMake Meister (Build system with a binary repository) - SVN - ### Common Details of all _Repositories_ Types - | Field | Description | | --- | --- | | **Full Domain Name** | The fully qualified name of the _Domain_ to which the _Repository_ was defined. | @@ -59,9 +56,6 @@ The Dashboard view displays all information related to a specific _Repository_ T | **Modified**| Auto-generated date when the _Repository_ was updated.| | **Credential**| The _Credential_ used to access the _Repository_ if required. | -NOTE: **DeployHub Team** has only two Groups, _Administrators_ and _Users_. If you need more granularity in your UserGroups, you will need to upgrade to **DeployHub Pro.** -{{% include "/userguide/reusable/Git.md/" %}} - ## HTTP _Repository_ Details @@ -105,7 +99,6 @@ NOTE: **DeployHub Team** has only two Groups, _Administrators_ and _Users_. If y |**Version Encrypted** | Select the box to indicate the Version should be hidden in the database.| |**Version Override** |Select the box if the Version can be replaced at the _Component_ definition.| -{{% include "/userguide/reusable/Git.md/" %}} {{% include "/userguide/reusable/OpenMake Meister.md/" %}} {{% include "/userguide/reusable/SVN.md/" %}} diff --git a/content/en/userguide/First Steps/2 Define Your Credentials.md b/content/en/userguide/First Steps/2 Define Your Credentials.md index bcdc84b7..ff739c4e 100644 --- a/content/en/userguide/First Steps/2 Define Your Credentials.md +++ b/content/en/userguide/First Steps/2 Define Your Credentials.md @@ -41,7 +41,7 @@ The Dashboard view displays all information related to a specific _Credential_. | **Full Domain** | The fully qualified path of the Domain to which the Credential belongs. | | **Name** | The name of the _Credential._ | | **Summary** | A general description of the _Credential._ | -| **Kind** | The type of _Credential_. There are two different types of _Credentials_: | +| **Tyoe** | The kind of _Credential_. There are two different Types of _Credentials_: | |**Owner Type**| _User_ or _Group_.| |**Owner**| The _User_ name or _Group_ name who created the _Credential_.| | **Created** | The date and time the _Credential_ was created. | @@ -72,9 +72,9 @@ The Access Section allows _Users_ within designated _Groups_ to update the _Cred | Access | Description | | --- | --- | -| _**View**_ | Allows the _User_ to see the _Credential_. If the _User_ does not belong to a _Group_ in the View Access list, the _Credential_ will not appear in the List View. | -| _**Change**_ | Allows the _User_ to change the _Credential’s_ characteristics i.e. Name, Summary, etc. | -| _**Read**_ | Allows the _User_ to use the _Credential_ by assigning it to an object such as an _EndPoint_ or _Repository_. | +| **View** | Allows the _User_ to see the _Credential_. If the _User_ does not belong to a _Group_ in the View Access list, the _Credential_ will not appear in the List View. | +| **Change** | Allows the _User_ to change the _Credential’s_ characteristics i.e. Name, Summary, etc. | +| **Read** | Allows the _User_ to use the _Credential_ by assigning it to an object such as an _EndPoint_ or _Repository_. | NOTE: **DeployHub Team** has only two Groups, _Administrators_ and _Users_. If you need more granularity in your _Groups_, you will need to upgrade to **DeployHub Pro.** diff --git a/content/en/userguide/Packaging Applications/2 Defining Applications.md b/content/en/userguide/Packaging Applications/2 Defining Applications.md index d2e937be..db75ff17 100644 --- a/content/en/userguide/Packaging Applications/2 Defining Applications.md +++ b/content/en/userguide/Packaging Applications/2 Defining Applications.md @@ -39,13 +39,13 @@ The _Application_ List View has the following Tabs. | Tab | Description | | --- | --- | -| Refresh | Refreshes the browser. | -| Add Base | Allows you to Add a new _Application Base Version_. | -| Add Version | Creates a copy of the selected _Application_ in the list, creating a new _Application Version_. | -| Delete | Deletes the selected item. However, you must delete the _Applications_ starting from the newest to the oldest. The _Application Base Version_ would be deleted last. Sorting by "Version" gives you the order. | -| Tasks | Displays all _Application_ Tasks available for the selected item based on the Tasks defined to the _Application_ Domain. See [Tasks](/userguide/first-steps/2-defining-domains/#tasks) for more information. | -| List | Displays the List View. | -| Map | Displays a global Map of all versions of the _Application_ with _Components_. | +| **Refresh** | Refreshes the browser. | +| **Add Base** | Allows you to Add a new _Application Base Version_. | +| **Add Version** | Creates a copy of the selected _Application_ in the list, creating a new _Application Version_. | +| **Delete** | Deletes the selected item. However, you must delete the _Applications_ starting from the newest to the oldest. The _Application Base Version_ would be deleted last. Sorting by "Version" gives you the order. | +| **Tasks** | Displays all _Application_ Tasks available for the selected item based on the Tasks defined to the _Application_ Domain. See [Tasks](/userguide/first-steps/2-defining-domains/#tasks) for more information. | +| **List** | Displays the List View. | +| **Map** | Displays a global Map of all versions of the _Application_ with _Components_. | ## Viewing and Editing with the _Application_ Dashboard @@ -53,19 +53,19 @@ The Dashboard view displays all information related to a specific _Application B | Details | Description | | --- | --- | -|Full Domain | The fully qualified path of the _Domain_ that the _Application_ is to be associated with, showing all parent _Domains_. | -|Name | The Name of your _Application_. | -|Owner Type| Owned by a User or Group. | -|Owner | Name of User or Group. | -|Summary | Description of the _Application_. | -|Created | The date the _Application_ was added. | -|Modified | The date the _Application_ was updated. | -|Change Request DataSource | DeployHub Pro Option - Establishes the Change Request system for the _Application_. A Change Request Data Source must be pre-defined for this field to be used. | -Pre-Action| An action executed prior to the deployment.| -Post-Action| An action executed at the completion of deployment.| -Custom Action | Overrides any Pre or Post Actions, such as calling an external solutions such as Helm.| -Successful Deployment Template | Used for success notifications. | -Failed Deployment Template| Used for failure notifications.| +|**Full Domain** | The fully qualified path of the _Domain_ that the _Application_ is to be associated with, showing all parent _Domains_. | +|**Name** | The Name of your _Application_. | +|**Owner Type**| Owned by a User or Group. | +|**Owner** | Name of User or Group. | +|**Summary** | Description of the _Application_. | +|**Created** | The date the _Application_ was added. | +|**Modified** | The date the _Application_ was updated. | +|**Change Request DataSource** | DeployHub Pro Option - Establishes the Change Request system for the _Application_. A Change Request Data Source must be pre-defined for this field to be used. | +|**Pre-Action**| An action executed prior to the deployment.| +|**Post-Action**| An action executed at the completion of deployment.| +|**Custom Action** | Overrides any Pre or Post Actions, such as calling an external solutions such as Helm.| +|**Successful Deployment Template** | Used for success notifications. | +|**Failed Deployment Template**| Used for failure notifications.| ### _Application_ Dependency Map @@ -101,13 +101,7 @@ The Difference Graph shows what changed in the last deployment between the previ The Trends graph shows the success or failure rates overtime as well at the time required for the last 10 deployments. If an _Application_ deployment takes longer than previous deployments, there is an issue with the deployment logic. -### Change Request - -The Change Request section, available for DeployHub Pro users, shows enhancement requests and bugs for a selected _Application_. You must have a "Change Request" Data Source defined in your General settings in order to see Change Requests. Change Request Data Sources can be connected to several popular bug tracking systems, including Bugzilla, GitHub, and Jira. To setup your Change Request see [Managing Data Sources](/userguide/customizations/2-data-sources/). - -Select the "+Add Change Request to this Version" to assign a Change Request to the _Application_. This will display all the Change Requests (Enhancements, Bugs, etc.) from the assigned Data Source in the resulting Select Bug Record pop up window. One or more of these can be assigned to the _Application_ by clicking on the box to the left of each CR ID field. - -The lower section contains a list of Change Requests with the fields CR ID, Title, and Status. Clicking on the CR ID takes the User to a new tab in the browser that contains the source of the Change Request. For instance, if the _Application_ has a Change Request Data Source of the type GitHub, clicking on the CR ID field for a Change Request will open a tab with the bug or enhancement request within github.com. This allows the User the ability to update, close, or read about it in detail. The Title field holds the title of the Change Request within the bug tracking system. The various bug tracking systems used by DeployHub have their own statuses. Bugzilla for instance, has statuses such as New, Unconfirmed, Assigned, etc. DeployHub interprets these as either 'open' or 'closed’ and displays them in the Status field with a gold or dark gray background respectively. +{{% include "userguide/reusable/ChangeRequest.md" %}} ## Package Components Tab diff --git a/content/en/userguide/Publishing Components/2 Define Components.md b/content/en/userguide/Publishing Components/2 Define Components.md index 5988777c..79d9f3b8 100644 --- a/content/en/userguide/Publishing Components/2 Define Components.md +++ b/content/en/userguide/Publishing Components/2 Define Components.md @@ -36,12 +36,12 @@ You can also use the Filter bar, represented by a funnel icon, to reorder your _ | Tab | Description | | --- | --- | -|Refresh | Refreshes the browser. | -| +Add Base | Allows you to Add a new _Component Base Version_. You will select from one of three types: Container, Application File, Database | -| +Add Version | Creates a copy of the selected _Component_. | -| Delete | Deletes the selected item. However, you must delete the _Components_ starting from the newest to the oldest. The _Component Base Version_ would be deleted last. Sorting by "Version" gives you the order. | -| List | Return to List View if in the Map View. | -| Map | Displays a global Map of all _Component_ versions, with their _Application_ relationships. | +|**Refresh** | Refreshes the browser. | +| **+Add Base** | Allows you to Add a new _Component Base Version_. You will select from one of three types: Container, Application File, Database | +| **+Add Version** | Creates a copy of the selected _Component_. | +| **Delete** | Deletes the selected item. However, you must delete the _Components_ starting from the newest to the oldest. The _Component Base Version_ would be deleted last. Sorting by "Version" gives you the order. | +| **List** | Return to List View if in the Map View. | +| **Map** | Displays a global Map of all _Component_ versions, with their _Application_ relationships. | ## _Component_ Types @@ -49,9 +49,9 @@ When adding new _Components_ select the _Component_ Type from the drop down lis | **Type** | **Description** | | --- | --- | -| Container | For Containers such as Docker. | -| Application File | For binary files such as .jar, .war, .ear, .exe, .dll, Linux executable files, Oracle Forms, or similar artifacts. | -| Database | For SQL files such as .ddl or other database update scripts. | +| **Container** | For Containers such as Docker. | +| **Application File** | For binary files such as .jar, .war, .ear, .exe, .dll, Linux executable files, Oracle Forms, or similar artifacts. | +| **Database** | For SQL files such as .ddl or other database update scripts. | ## How to View and Edit _Components_ @@ -69,7 +69,8 @@ The following fields are common to all _Components_: | **Summary** | A short text field with a description of the _Component_. | | **Created** | The date and time that the _Component_ was created. | | **Modified** | The date and time of the last change. | -| **Kind**| Container, Application File, or Database.| +| **Object**| Displays _Component_ for the Base Version or _Component Version_.| +| **Type**| The kind of Component created, i..e. Container, Application File, or Database.| |**Endpoint Type** | Used to map the _Component_ to _Endpoints_ within an _Environment_ at deployment. This allows DeployHub to map the _Component_ to the correct _Endpoint_ when moving across different environments. You can add your own _Endpoint_ Types from the Customize Types menu or select from the default options.| | **Change Request Data Source** | This _Data Source_ is assigned to the _Component_ for tracking Change Request. A Change Request Data Source must be pre-defined for this field to be used. | | **Category** | Assigning a Category to an Object allows lists of Objects based on Categories to be used throughout DeployHub. Add a new Category in the entry field or use an existing Category displayed in the drop down. Categories are most commonly associated with _Actions_, _Functions_ and _Procedures_. Pre-defined Categories include:
  • Build - _Actions_, _Functions_ and _Procedures_ for calling ANT (SalesForce integration).
  • Database - _Actions_, _Functions_ and _Procedures_ for database updates.
  • Deploy- _Actions_, _Functions_ and _Procedures_ for Deployments.
  • Dropzone- _Actions_, _Functions_ and _Procedures_ for interacting with the Dropzone.
  • File Logic- _Actions_, _Functions_ and _Procedures_ related to File manipulation.
  • Flow Logic- _Actions_, _Functions_ and _Procedures_ for if then else in DMScript.
  • Loops- _Actions_, _Functions_ and _Procedures_ for file looping.
  • General-Non-categorized Objects (default).
  • WebLogic- _Actions_, _Functions_ and _Procedures_ for deploying to WebLogic.
  • WebSphere- _Actions_, _Functions_ and _Procedures_ for deploying to WebSphere.
  • Windows- _Actions, Functions_ and _Procedures_ used for Windows deployments.
    • | @@ -180,13 +181,7 @@ The Access Section allows _Users_ within designated _Groups_ to update or view t | **View** | This allows any _User_ that belongs to any _Group_ in this list to see the selected _Component_ in the List View. | | **Change** | This allows any _User_ that belongs to any _Group_ in this list to make changes to the _Component_. | -### Change Request - -The Change Request section, available for DeployHub Pro users, shows enhancement requests and bugs for a selected Component for several popular bug tracking systems, including Bugzilla, GitHub, and Jira. - -Select the "+Add Change Request to this Version" to assign a Change Request to the _Component_. This will display all the Change Requests (Enhancements, Bugs, etc.) from the assigned Data Source in the resulting Select Bug Record pop up window. One or more of these can be assigned to the _Component_ by clicking on the box to the left of each CR ID field. - -The lower section contains a list of Change Requests with the fields CR ID, Title, and Status. Clicking on the CR ID to see the source of the Change Request. For instance, if the _Component_ has a Change Request Data Source of the type GitHub, clicking on the CR ID field for a Change Request will open a tab with the bug or enhancement request within github.com, allowing the User the ability to update, close, or read about it in detail. The Title field holds the title of the Change Request within the bug tracking system. The various bug tracking systems used by DeployHub have their own statuses. Bugzilla for instance, has statuses such as New, Unconfirmed, Assigned, etc. DeployHub interprets these as either 'open' or 'closed’ and displays them in the Status field with a gold or dark gray background respectively. +{{% include "userguide/reusable/ChangeRequest.md" %}} ## Publish a New _Component Version_ Based on an Existing _Component Version_ diff --git a/content/en/userguide/concepts/3 Executing Deployments.md b/content/en/userguide/concepts/3 Executing Deployments.md index fe9eb35b..eb20c3a0 100644 --- a/content/en/userguide/concepts/3 Executing Deployments.md +++ b/content/en/userguide/concepts/3 Executing Deployments.md @@ -44,13 +44,30 @@ An on-demand deployment can be initiated for an _Application_ or _Release_ using You execute a roll forward or rollback deployment on-demand. To roll forward or rollback, go to the [_Application_ List View](/userguide/packaging-applications/2-defining-applications/#the-_application_-list-view-for-adding-or-deleting), select the new or older _Application Version_ you wish to deploy and use the _Deploy Task_ available from the Task Tab. This will push the selected version to the cluster incrementally. -### Using the Smart Calendar for Scheduling Deployments +## DeployHub and Your Continuous Delivery (CD) Pipeline -DeployHub Pro users can take advantage of scheduling deployments via "smart" calendars. Each _Environment_ has its own calendar for managing deployments. You can reserve a time slot on the Smart Calendar to do a manual deployment, or "Auto deploy" using the _Deploy Task_. See [Smart Environment Calendars](/userguide/first-steps/2-define-environments/#smart-_environment_-calendars) for more information. +DeployHub is added to your CD pipeline to perform continuous configuration management of your _Applications_ and _Components_, and to push them to runtime _Environments_ across your defined lifecycle. -### Continuous Delivery and DeployHub +DeployHub uses a built-in deployment pipeline for tracking an _Application's_ journey across a software delivery lifecycle, i.e. Dev, Test, Production. However, it is important to understand that a DeployHub Lifecycle _Subdomain_ is not intended to replace your CD orchestration solution. DeployHub integrates with your CD pipeline becoming a part of your overall ecosystem for versioning, tracking and deploying software to clusters, cloud environments and physical data centers. -DeployHub can be called from your continuous delivery orchestration solution to perform both continuous configuration management and deployments of your _Application_ and associated _Components_ like microservices. DeployHub integrates into your CD pipeline using standard Task including Approve, Move and Deploy. DeployHub has standard integrations with Continuous Delivery solutions. If your CD tool is not supported, you can build out the integration using APIs that call the DeployHub Tasks. +DeployHub tracks an _Application's_ configuration including where it is in the lifecycle in terms of _Environments_. An _Environment_ is assigned to a lifecycle _Subdomain_. Therefore, we can track where a _Component_ or _Application_ is in the lifecycle based on where it has been installed. Each Lifecycle _Subdomain_ can contain multiple _Environments_. Regardless of what _Environment_ an _Application_ is running in, DeployHub can still track where it is in the Lifecycle process based on the Lifecycle _Subdomain_. This is the core function of Lifecycle _Subdomains_. + +A Lifecycle _Subdomain_ is the lowest level _Domain_. You can not create a _Subdomain_ off of a Lifecycle _Subdomain_. + + +### Using a Lifecycle Subdomain + +When you create a Lifecycle Subdomain, you provide a means to include lifecycle state information as part of your _Application's_ configuration. For each state of your software delivery lifecycle, you create an associated Lifecycle _Subdomain_ for your _Application_. You do this by using the _Domain_ Dashboard. Navigate to your _Application's_ _Domain_, select the "All _Subdomains_ are Lifecycles" checkbox, and then add your child _Subdomains_. All _Subdomains_ will represent your Lifecycle process. You will need to navigate to the _Environment_ Dashboard to add the _Environments_ to your Lifecycle _Subdomains_. + +### Establishing the Progression Order of Your Lifecycle + +You can force the progression of your lifecycle process by adding a "Move" Task to the lifecycle _Subdomain_. At the "Move" Task level, you define what Lifecycle _Subdomain_ will be the next state (the "move to _Domain_). This is how DeployHub clearly defines the order of how an _Application_ should progress through the lifecycle, i.e. first development, then test, and finally production. A "Move" Task does not perform a deployment, it just stages the _Application_ for a deployment into the _Environments_ associated with that Lifecycle _Subdomain. + +To deploy an _Application_ into an _Environment_ make sure that the Deploy Task is assigned to the _Domain_. The Deploy Task is the default Task for all newly created _Domains. + +### Your Lifecycle _Subdomains_ and your Continuous Delivery Engine + +Your continuous delivery (CD) engine will define your lifecycle progression. When you integrate DeployHub into your existing CD Pipeline, you will need to define your Lifecycle _Subdomains_ to mimic your CD Workflow progression. You can then associate integration of each of your CD Workflows directly to a DeployHub Lifecycle _Subdomain_. You can perform calls to DeployHub to both "Move" and "Deploy" _Applications_ into _Environments_. If you are a DeployHub Pro users, you can also call "Request" and "Approve" Tasks as part of your integration. These Tasks interact with DeployHub Pro "Smart" calendars, not available in DeployHub Team. See [Using DeployHub with CI/CD](/userguide/integrations/CI-CD_Integrations.md) for more information on connecting your CI/CD solution to DeployHub. {{% include "userguide/reusable/Tasks.md" %}} diff --git a/content/en/userguide/concepts/LifecycleSubDomains.md b/content/en/userguide/concepts/LifecycleSubDomains.md new file mode 100644 index 00000000..671145a0 --- /dev/null +++ b/content/en/userguide/concepts/LifecycleSubDomains.md @@ -0,0 +1,39 @@ +--- +title: "Using Lifecycle _Subdomains_" +linkTitle: "Using Lifecycle _Subdomains_" +weight: 42 +description: > + Using Lifecycle _Subdomains_ and Pipelines +--- +## Introduction to Lifecycle _Subdomains_ + +DeployHub uses a built-in deployment pipeline for tracking an _Application's_ journey across a software delivery lifecycle, i.e. Dev, Test, Production. However, it is important to understand that a DeployHub Lifecycle _Subdomain_ is not intended to replace your continuous delivery (CD) orchestration solution. In fact, there is integration that allows DeployHub to be called by your CD pipeline so it becomes part of your overall ecosystem for performing continuous configuration management and continuous deployment. + +DeployHub tracks an _Application's_ configuration including where it is in the lifecycle in terms of _Environments_. An _Environment_ is assigned to a lifecycle _Subdomain_. Therefore, we can track where a _Component_ or _Application_ is in the lifecycle based on where it has been installed. Each Lifecycle _Subdomain_ can contain multiple _Environments_. Regardless of what _Environment_ an _Application_ is running in, DeployHub can still track where it is in the Lifecycle process based on the Lifecycle _Subdomain_. This is the core function of Lifecycle _Subdomains_. + +A Lifecycle _Subdomain_ is the lowest level _Domain_. You can not create a _Subdomain_ off of a Lifecycle _Subdomain_. + + +## Using a Lifecycle Subdomain + +When you create a Lifecycle Subdomain, you provide a means to include lifecycle state information as part of your _Application's_ configuration. For each state of your software delivery lifecycle, you create an associated Lifecycle _Subdomain_ for your _Application_. You do this by using the _Domain_ Dashboard. Navigate to your _Application's_ _Domain_, select the "All _Subdomains_ are Lifecycles" checkbox, and then add your child _Subdomains_. All _Subdomains_ will represent your Lifecycle process. You will need to navigate to the _Environment_ Dashboard to add the _Environments_ to your Lifecycle _Subdomains_. + +### Establishing the Progression Order of Your Lifecycle + +You can force the progression of your lifecycle process by adding a "Move" Task to the lifecycle _Subdomain_. At the "Move" Task level, you define what Lifecycle _Subdomain_ will be the next state (the "move to _Domain_). This is how DeployHub clearly defines the order of how an _Application_ should progress through the lifecycle, i.e. first development, then test, and finally production. A "Move" Task does not perform a deployment, it just stages the _Application_ for a deployment into the _Environments_ associated with that Lifecycle _Subdomain. + +To deploy an _Application_ into an _Environment_ make sure that the Deploy Task is assigned to the _Domain_. The Deploy Task is the default Task for all newly created _Domains. + +### Your Lifecycle _Subdomains_ and your Continuous Delivery Engine + +Your continuous delivery (CD) engine will define your lifecycle progression. When you integrate DeployHub into your existing CD Pipeline, you will need to define your Lifecycle _Subdomains_ to mimic your CD Workflow progression. You can then associate integration of each of your CD Workflows directly to a DeployHub Lifecycle _Subdomain_. You can perform calls to DeployHub to both "Move" and "Deploy" _Applications_ into _Environments_. If you are a DeployHub Pro users, you can also call "Request" and "Approve" Tasks as part of your integration. These Tasks interact with DeployHub Pro "Smart" calendars, not available in DeployHub Team. + + + +Tasks + +Any combination of Tasks can be defined to your Lifecycle _Subdomain_. Tasks are defined and linked from the _Domain_ Dashboard. + + +_Domains_ and their Tasks are a core concept of how DeployHub manages deployments and deployment authorization. To learn more, see [Building Your Domain Catalog](/userguide/first-steps/2-defining-domains/). + diff --git a/content/en/userguide/integrations/Ansible Playbook.md b/content/en/userguide/integrations/Ansible Playbook.md index b6c93fb9..d912ae40 100644 --- a/content/en/userguide/integrations/Ansible Playbook.md +++ b/content/en/userguide/integrations/Ansible Playbook.md @@ -36,15 +36,13 @@ Now we are going to customize this Action. You will see the 'Activity Hub' on th ### _GitCheckout_ Parameters -| _**Field**_ | Value | Description | +| **Field** | Value | Description | | --- | --- | --- | -| _**Title**_ | Not Required | - | -| _**Summary**_ | Not Required | - | -| _**Git Repo**_ | $GIT_URL| Repo containing the Playbook | -| _**Git Commit**_ | $GIT_COMMIT | The commit, tag or branch to checkout | -| _**To Dir**_ | $GIT_DIR | The directory to checkout into. Use "." for the default directory | +| **Title** | Not Required | Name of the step in your deployment workflow. | +| **Summary** | Not Required | Enter a summary of this step. | | +| **Git Repo** | $GIT_URL| Repo containing the Playbook | +| **Git Commit** | $GIT_COMMIT | The commit, tag or branch to checkout | +| **To Dir** | $GIT_DIR | The directory to checkout into. Use "." for the default directory | ### _WriteEnv2File_ Parameters @@ -52,11 +50,11 @@ No fields are required for _WriteEnv2File_. ### _RunAnsiblePlaybook_ Parameters -| _**Field**_ | Value | Description | +| **Field** | Value | Description | | --- | --- | --- | -| _**Title**_ | Not Required | | -| _**Summary**_ | Not Required | | -| _**RspFile**_ | $RspFile | The results from the WriteEnv2Toml.re Procedure | +| **Title** | Not Required | Name of the step in your deployment workflow. | +| **Summary** | Not Required | Enter a summary of this step. | | +| **RspFile** | $RspFile | The results from the WriteEnv2Toml.re Procedure | At this point the Action is ready to be used by anyone with access (based on Domain and security options). Each Component that uses the Action will need to define specific values. Because this new Action is reusable, no Component variables are defined. diff --git a/content/en/userguide/integrations/Git.md b/content/en/userguide/integrations/Git.md deleted file mode 100644 index 13d4b8ba..00000000 --- a/content/en/userguide/integrations/Git.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: "Git" -linkTitle: "Git" -weight: 61 -description: > - Integrating Git repository with DeployHub. ---- - -{{% include "/userguide/reusable/Git.md/" %}} diff --git a/content/en/userguide/integrations/GitHub.md b/content/en/userguide/integrations/GitHub.md index 778133bf..051491c3 100644 --- a/content/en/userguide/integrations/GitHub.md +++ b/content/en/userguide/integrations/GitHub.md @@ -6,96 +6,60 @@ description: > Integrating GitHub repository and issues with DeployHub Pro. --- -DeployHub supports GitHub in three ways. +DeployHub supports GitHub in the following ways. -1. Repository for artifacts which can be any type of object such as binaries or Python scripts. +1. A binary Repository for retrieving artifacts to deploy such as binaries or scripts. 2. GitHub Issue Tracking for **DeployHub Pro**. A bridge connects a GitHub issue with a DeployHub Change Request. -3. Wiki updates for collaborating DeployHub output. -## GitHub Repository Connection +## GitHub as a Binary Repository -GitHub can store any type of object in its Repository. These objects are referenced through Git Commits, Tags, and Branches. DeployHub performs a check-out of these objects as part of the Pre-Actions to a Component Version or Application Version. This Git Check-out places the files into the DropZone for pre-processing prior to the deployment. +You can configure DeployHub to call out to a Git Repo to pull deployable artifacts (binaries, scripts, etc.) as part of your deployment. The process will check out your deployable artifacts based on commit, branch or tag specified. You will need to configure DeployHub with a file system DeployHub _Repository_ that will pull the files need fro the deployment. You will also need to create a "Git Checkout" _Procedure_ and _Action_. -Using the GitHub Repository requires a two-step process. First is the Git checkout to the file system and second references the checked-out files using the _File System Repository_. The git checkout is done using the GitCheckOutAction as a Pre-Action to the Component. This then places the files so that the File System Repository will reference them for deployment. +**Step 1 - Create a DeployHub File System _Repository_** -## Creating the GitHub Checkout Action +DeployHub can use GitHub as a binary repository for retrieving deployable objects as part of the deployment process. To do this you will first need to define GitHub as a connected _Repository_ Object from within DeployHub. This connection will be used by as part of the deployment process using a _Procedure_ and a _Action_. For information on setting up File System as a binary repository see [Connect Your Repositories](/userguide/first-steps/2-define-repositories/). -### Importing the Procedures +Once you have completed this step, you are ready to create a new _Procedure_ that performs the check out from the GitHub repository. - You will need to import the most current Git Procedure from GitHub. +**Step 2 - Create your GitHub Checkout _Procedure_ for your _Action_** -- **GitCheckout.re** - This _Procedure_ clones the repo to the _Dropzone_ and then checks out the commit, branch or tag specified. +_Procedures_ are called by _Actions_ to execute deployment logic. A pre-defined DeployHub _Procedure__ is available from the [Ortelius Git Repo](https://github.com/ortelius/ortelius/blob/master/procedures/). This where you will find the most current version of this _Procedure_. For more information on creating _Procedures see [Functions and Procedures](/userguide/customizations/2-define-your-functions-and-procedures/). -Download them from: +From the Ortelius Git Repo, pull the file named **GitCheckout.re** -[Ortelius Git Repo](https://github.com/ortelius/ortelius/blob/master/procedures/) +Once downloaded, you will need to Import it into DeployHub from the Func/Procs List View. Navigate to the List View by selecting the Func/Procs menu option on the left hand side of the DeployHub main panel. From the Func/Procs List view select the **Import** option. The Import will bring you to your operating system "file open" dialog box for selecting the GitCheckout.re file. Next, select your _Domain_ and upload the _Procedure_ into the DeployHub. You are now ready to create your _Action_. -Once downloaded, you will need to Import them into DeployHub as the Procedures. To import these Procedures login to DeployHub and select the _Func/Procs_. From the list view select **Import** menu. Select your Domain, such as '_Global_ Domain' and upload the _Procedure_ into the DeployHub. +**Step 3 - Create your _Action_ for the GitHub Checkout _Procedure_** -## New Action for the GitHub Checkout +Once you have imported your GitCheckout.re _Procedure_, you can define your _Action_. Navigate to the _Actions_ list view from the _Actions_ menu option on the left hand side of the DeployHub main panel. Use the +Add option to create a new _Action_ for you _Procedure_. Name the new _Action_ **GitCheckAction** (no spaces). See [Customize Your Actions](/userguide/customizations/2-define-your-actions/) for more information on creating _Actions_. -Once you have imported your _Procedures_, you can define your _Action_. Change to the _Actions_ list view and select "Add" menu. +Now we are going to customize this _Action_. On the right hand side, you will see a list of _Functions_ and _Procedures_ you can choose from. Navigate to your _Domain_ to find the GitCheckOut _Procedure_. Drag it onto the area under _Start._ -Name the new Action "GitCheckAction" (no spaces). +_GitCheckout_ Parameters -Now we are going to customize this _Action_. You will see the 'Activity Hub' on the Righthand side of your screen. Navigate to your Domain to find the _Procedures_. Drag them onto the area under _Start._ - -### _GitCheckout_ Parameters - -| _**Field**_ | Value | Description | +| **Field** | Value | Description | | --- | --- | --- | -| _**Title**_ | Not Required | - | -| _**Summary**_ | Not Required | - | -| _**Git Repo**_ | $GIT_URL| Repo containing the Playbook | -| _**Git Commit**_ | $GIT_COMMIT | The commit, tag or branch to checkout | -| _**To Dir**_ | $GIT_DIR | The directory to checkout into. Use "." for the default directory | - -At this point the Action is ready to be used by anyone with access (based on Domain and security options). Each Component that uses the Action will need to define specific values. Because this new Action is reusable, no Component variables are defined. - -### Assign the _GitCheckoutAction_ to a Component - -For each _File Component_ you will need to define the variable values. These values will override those defined at the _Application_ or _Environment_ level. The values from DeployHub will be passed along to the GitCheckoutAction__ at execution time. - -## GitHub Issues in DeployHub Pro - -DeployHub Pro can reference the GitHub issues for a particular GitHub _Repository_. _Components_ can only be associated to a single GitHub _Repository_. In DeployHub Pro, you can associate issues to a _Component Version_ or _Application Version_. This enables the GitHub issues to be viewed from a _Component_ or _Application_ using the DeployHub Pro _Change Request_ tab. If you have a _Release_ defined, these GitHub issues will be rolled up from the _Component_ and _Application_ to the _Release_. - -To associate your GitHub Repository with DeployHub Pro you need to define a _Data Source_ connection with the _Type_ of "GitHub." This is done from the _Connections_ Menu under the _Data Source_ tab. Right click on your Domain name and select "New Data Source in this Domain." Complete the following fields: - -## GitHub Data Source Connection General Tab - -| Field | Description | -| --- | --- | -| Name | Enter a unique name for the Data Source. | -| Type | Select "GitHub. | -| Owner Type | Select User or Group who will be the owner of the Data Source (Group Ownership or User Ownership). | -| Users/Group | Select the Group or Users that will be the owner. | -| Summary | Describe the Data Source. | -| Credentials | Select the Credentials needed for accessing the GitHub Repository. NOTE: You must create your Credentials from the Credentials tab under the Connections menu. - | - -Once completed, you need to select the Properties tab and click on the Plus (+) sign to add the following properties: - -## GitHub Data Source Properties +| **Title** | Not Required | Name of the step in your deployment workflow. Use "Git Checkout." | +| **Summary** | Not Required | Enter a summary of this step. | +| **Git Repo** | $GIT_URL| This Variable represents the Git Repo containing the deployable artifacts. The value will be defined at the Component Level. | +| **Git Commit** | $GIT_COMMIT | This Variable represents the Git the commit, tag or branch to checkout. The value will be defined at the Component Level.| +| **To Dir** | $GIT_DIR | This Variable represents the directory to checkout into. The value will be defined at the Component Level. Use "." for the default directory when assigning this value at the Component level. | -| Field | Description | -| --- | --- | -| Product | The name of your Repository. | -| Repository | The name of your Repository Owner. | +At this point the _Action_ is ready to be used by anyone with access (based on _Domain_ and _Group_ options). +Note: Because this _Action_ is reusable, no _Component_ variables are defined. This is performed at the _Component_ level. -You are now ready to associate your GitHub issues with your DeployHub Pro Components and/or Applications. +**Step 4 - Assign the GitCheckoutAction to your _Component_ to be deployed** -## Selecting a GitHub Issue to a Component or Application +For each _Component_ you will need to define the variable values for $GIT_URL, $GIT_COMMIT and $GIT_DIR that the GitCheckoutAction will use at the _Component_ level. The values will be passed to the GitCheckoutAction at deploy time. See [Defining _Components_](/userguide/publishing-components/2-define-components/) for more information. -Use the _Change Request_ section at the bottom of a _Component_ or _Application_ details screen to add and delete GitHub issues. +## GitHub Issues and DeployHub Pro Change Request -## GitHub Wiki and DeployHub +DeployHub Pro can reference the GitHub issues to track Change Request for _Components_ and _Applictions_. This enables the GitHub issues to be viewed from a _Component_ or _Application_ using the DeployHub Pro _Change Request_ section from the _Component_ or _Application_. If you have a _Release_ defined, these GitHub issues will be rolled up from the _Component_ and _Application_ to the _Release_. -The GitHub Wiki page can be used to consolidate deployment output using both DeployHub Team and Pro. The GitHub Wiki is implemented as a Git Repository. Because of this, DeployHub can check-out the Wiki, update the contents, and commit the changes. The Wiki is processed as part of the deployment Workflow. To add the Wiki updates, you define a Post Action to the Application. Your Post Action calls an external script that updates and commits the Wiki. You will need to create the external script. +For more information see [Tracking Jira, Bugzilla and GitHub Issue](/userguide/integrations/jira-bugzilla-and-git-issues/). -For more information: +Additional information: -- [Managing DataSorces](userguide/customizations/2-data-sources/) -- [Connect Your Repositories](userguide/first-steps/2-define-repositories/) +- [Managing _Data Sources_](userguide/customizations/2-data-sources/) +- [Connect Your _Repositories_](userguide/first-steps/2-define-repositories/) +- [Defining _Components_](/userguide/publishing-components/2-define-components/) \ No newline at end of file diff --git a/content/en/userguide/integrations/Helm.md b/content/en/userguide/integrations/Helm.md index 18654806..daecf003 100644 --- a/content/en/userguide/integrations/Helm.md +++ b/content/en/userguide/integrations/Helm.md @@ -39,13 +39,11 @@ No fields are required for _WriteEnv2File_. | Field | Value | Description | | --- | --- | --- | -| _**Title**_ | Not Required | - | -| _**Summary**_ | Not Required | - | -| _**RspFile**_ | $RspFile | The results from the WriteEnv2Toml.re Procedure | -| _**Chart**_ | $(Chart) | The Helm Chart to be used during the deployment | -| _**Release Name**_ | $(component.name) | The name of the release | +| **Title** | Not Required | Name of the step in your deployment workflow. | +| **Summary** | Not Required | Enter a summary of this step. | | +| **RspFile** | $RspFile | The results from the WriteEnv2Toml.re Procedure | +| **Chart** | $(Chart) | The Helm Chart to be used during the deployment | +| **Release Name** | $(component.name) | The name of the release | At this point the Action is ready to be used by anyone with access (based on Domain and security options). Each Component that uses the Action will need to define specific values. Because this new Action is reusable, no Component variables are defined. @@ -57,31 +55,31 @@ Docker component items have the following attributes, none of which are required | Field | Description | | --- | --- | -| _**BuildId**_ | The build ID from the build system such as Quay or DockerHub | -| _**BuildUrl**_ | Build URL for the build system | -| _**Chart**_ | Helm chart for the component | -| _**Chart Version**_ | Version of the Helm chart | -| _**Chart Name Space**_ | Namespace for the Helm chart to deploy to | -| _**Operator**_ | Kubernetes Operator | -| _**DockerBuildDate**_ | Timestamp for the Docker Build | -| _**DockerSha**_ | SHA for the Docker Image | -| _**DockerRepo**_ | URL for the Docker Registry | -| _**GitCommit**_ | Git Commit that triggered the Build | -| _**GitRepo**_ | Git Repo Name | -| _**GitTag**_ | Git Tag such as 'Master' or 'v1.5.0' | -| _**GitUrl**_ | URL to the Git Repository | -| _**BuildNumber**_ | Build Job Number for CI/CD | -| _**Build Job**_ | Build Job name for CI/CD | -| _**ComponentType**_ | Name of the Component Type | -| _**ChangeRequestDS**_ | Name of the Change Request Datasource | -| _**Category**_ | Name of the Components Category | -| _**AlwaysDeploy**_ | Y/N | -| _**DeploySequentially**_ | Y/N | -| _**BaseDirectory**_ | Base Directory for the Component | -| _**PreAction**_ | Name of the Pre-Action | -| _**PostAction**_ | Name of the Post-Action | -| _**CustomAction**_ | Name of the Custom-Action | -| _**Summary**_ | Component Summary or Description | +| **BuildId** | The build ID from the build system such as Quay or DockerHub | +| **BuildUrl** | Build URL for the build system | +| **Chart** | Helm chart for the component | +| **Chart Version** | Version of the Helm chart | +| **Chart Name Space** | Namespace for the Helm chart to deploy to | +| **Operator** | Kubernetes Operator | +| **DockerBuildDate** | Timestamp for the Docker Build | +| **DockerSha** | SHA for the Docker Image | +| **DockerRepo** | URL for the Docker Registry | +| **GitCommit** | Git Commit that triggered the Build | +| **GitRepo** | Git Repo Name | +| **GitTag** | Git Tag such as 'Master' or 'v1.5.0' | +| **GitUrl** | URL to the Git Repository | +| **BuildNumber** | Build Job Number for CI/CD | +| **Build Job** | Build Job name for CI/CD | +| **ComponentType** | Name of the Component Type | +| **ChangeRequestDS** | Name of the Change Request Datasource | +| **Category** | Name of the Components Category | +| **AlwaysDeploy** | Y/N | +| **DeploySequentially** | Y/N | +| **BaseDirectory** | Base Directory for the Component | +| **PreAction** | Name of the Pre-Action | +| **PostAction** | Name of the Post-Action | +| **CustomAction** | Name of the Custom-Action | +| **Summary** | Component Summary or Description | or more information see: diff --git a/content/en/userguide/integrations/Intro to Integrations.md b/content/en/userguide/integrations/Intro to Integrations.md index 01ad9bdd..599e4b6e 100644 --- a/content/en/userguide/integrations/Intro to Integrations.md +++ b/content/en/userguide/integrations/Intro to Integrations.md @@ -14,12 +14,11 @@ DeployHub has an open architecture with many out of the box integrations with ot Integrations can be created using: -- _Notifiers_ for calling, Email, Slack or Hipchat. -- _Actions_ for deploying and managing Infrastructure Components like Tomcat or WebSphere. -- _Data Sources_ for connecting to outside data such as Change Request systems like Jira, Git or Bugzilla. -- _Custom Actions_ for performing deployments like Helm, Ansible and Cloud Foundry. -- _APIs_ for creating continuous delivery plug-ins for continuous configuration management. +- [_Notifiers_](/userguide/customizations/2-define-notifiers/) for calling, Email, Slack or Hipchat. +- [_Actions_ and _Custom Actions_](/userguide/customizations/2-define-your-actions/) for deploying and managing Infrastructure Components like Tomcat or WebSphere or performing deployments with Helm, Ansible or Cloud Foundry. +- [_Data Sources_](/userguide/profeatures/2-data-sources/) for connecting to outside data such as Change Request systems like Jira, Git or Bugzilla. +- [_APIs_](/userguide/restapi/) for creating continuous delivery plug-ins for continuous configuration management. {{% include "userguide/reusable/ListofActions.md" %}} -## Customizing Integrations + diff --git a/content/en/userguide/integrations/Jira, Bugzilla and Git Issues.md b/content/en/userguide/integrations/Jira, Bugzilla and Git Issues.md index 1b22d70e..5df74691 100644 --- a/content/en/userguide/integrations/Jira, Bugzilla and Git Issues.md +++ b/content/en/userguide/integrations/Jira, Bugzilla and Git Issues.md @@ -1,14 +1,11 @@ --- -title: "Tracking Jira, Bugzilla and Git Issues" -linkTitle: "Issue Tracking" +title: "Tracking Jira, Bugzilla and GitHub Issues" +linkTitle: "Tracking Jira, Bugzilla and GitHub Issues" weight: 69 description: > Tracking Change Request with DeployHub Pro. --- -If you are using DeployHub Pro, you can configure _Components_ with _Change Requests_. To do this, you will need to define a connection to the change request system. This can be done using _Data Sources_. +{{% include "userguide/reusable/ChangeRequest.md" %}} -Once your _Data Source_ has been defined, it will show as an option when defining your _Component_ in the _Change Request_ data field. Once connected and assigned to the _Component_, anytime a _Change Request_ has been opened against the _Component_ it will be tracked and displayed as part of the _Application_ Last Deployment Difference Map and will be available in the Change Request Section of both _Applications_ and _Components_. - -For more information on configuring Jira, Bugzilla or Git as a _Data Source_, go to: -[Managing Data Sources](/userguide/customizations/2-data-sources/) +For more information on using the _Component_ or _Application_ Dashboards for adding Change Request see [Publishing _Components_](/userguide/publishing-components/) and [Packaging _Applications_](/userguide/packaging-applications/). diff --git a/content/en/userguide/integrations/Salesforce.md b/content/en/userguide/integrations/Salesforce.md index 9db555cf..7d63d358 100644 --- a/content/en/userguide/integrations/Salesforce.md +++ b/content/en/userguide/integrations/Salesforce.md @@ -65,13 +65,13 @@ The _Action_ can now be placed into the _Custom Action field_ of a _Component_ a **GitCheckout Parameters** -| _**Field**_ | Value | Description | +| **Field** | Value | Description | | --- | --- | --- | -| _**Title**_ | Not Required | The name of the step. | -| _**Summary**_ | Not Required | Description of the step. | -| _**Git Repo**_ | $GIT_URL| Git Repo containing the SalesForce Source Code.| -| _**Git Commit**_ | $GIT_COMMIT | The commit, tag or branch to checkout. | -| _**To Dir**_ | $GIT_DIR | The directory to checkout into. Use "." for the default directory. | +| **Title** | Not Required | Name of the step in your deployment workflow. | +| **Summary** | Not Required | Enter a summary of this step. | | +| **Git Repo** | $GIT_URL| Git Repo containing the SalesForce Source Code.| +| **Git Commit** | $GIT_COMMIT | The commit, tag or branch to checkout. | +| **To Dir** | $GIT_DIR | The directory to checkout into. Use "." for the default directory. | **SalesforceCredential Parameters** diff --git a/content/en/userguide/integrations/Tomcat.md b/content/en/userguide/integrations/Tomcat.md index bc8eee33..5d24c222 100644 --- a/content/en/userguide/integrations/Tomcat.md +++ b/content/en/userguide/integrations/Tomcat.md @@ -20,15 +20,13 @@ Repeat the same steps for creating your "_Tomcat Post Deploy_" _Action_. ### _TomcatPreDeploy_ and _TomcatPostDeploy_ Parameters -| _**Field**_ | Value | Description | +| **Field** | Value | Description | | --- | --- | --- | -| _**Title**_ | Not Required | - | -| _**Summary**_ | Not Required | - | -| _**Tomcat Service Name**_ | $TOMCAT_SERVICE_NAME| The service running Tomcat | -| _**Tomcat Root**_ | $TOMCAT_ROOT | Tomcat web root | -| _**Application Name**_ | $APPLICATION_NAME | Application name (based on the .war or .ear) | +| **Title** | Not Required | Name of the step in your deployment workflow. | +| **Summary** | Not Required | Enter a summary of this step. | | +| **Tomcat Service Name** | $TOMCAT_SERVICE_NAME| The service running Tomcat | +| **Tomcat Root** | $TOMCAT_ROOT | Tomcat web root | +| **Application Name** | $APPLICATION_NAME | Application name (based on the .war or .ear) | At this point the Action is ready to be used by anyone with access (based on Domain and security options). Each Component that uses the Action will need to define specific values. Because this new Action is reusable, no Component variables are defined. diff --git a/content/en/userguide/pipeline/2 Defining Your Pipeline.md b/content/en/userguide/pipeline/2 Defining Your Pipeline.md deleted file mode 100644 index 0b729342..00000000 --- a/content/en/userguide/pipeline/2 Defining Your Pipeline.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Pipelines" -linkTitle: "Pipelines" -weight: 42 -description: > - DeployHub and your Pipeline Process ---- -## Pipelines - -The Delivery Pipeline defines a continuous delivery process for driving continuous deployments. You can use DeployHub independent of a continuous delivery engine such as Jenkins Blue Ocean, GitLab, Bamboo, or GitHub Actions. Alternatively, you can integrate to these types of tools allowing DeployHub to manage the continuous deployment steps and report back to these tools, logs, and success/fail messages. - -## Building your Delivery Pipeline - -The Delivery Pipeline contains all information for _Life Cycle Subdomains_ concerning the deployment of _Applications_ and their movement development through production release. It is designed to show and keep track of the procession of _Applications_ through the continuous delivery pipeline, as well as the deployment of _Applications_ into _Environments_. Keep in mind that when dealing with software lifecycles within DeployHub, parent _Domains_ contain _Life Cycle Subdomains_, and these contain Applications and Environments. All Move, Deploy, and Request _Tasks_ discussed in this section are utilized in the tree structure by right clicking on the _Applications_ within Lifecycle Domains. The results are viewed in the Delivery Pipeline tab for the parent Domain. - -The _Delivery Pipeline_ tab is only available in _Project Domains_ that contain _Life Cycle Subdomains_. _Applications_ can be moved forward or backward between Development, Test, and Production _Life Cycle Subdomains_, which have been arranged within the parent _Project__Domain_ in the correct continuous delivery pipeline order. Therfore, there could be three _Life Cycle Subdomains_ in the parent _Project Domain_ named appropriately, i.e. Dev, Test, and Prod, in that order. - -## Delivery Pipeline Process - -_Applications_ can be moved between _Life Cycle Subdomains_ with a _Move Task_. Any _User_ with access to that specific _Move Task_, which designates which _Project Domain_ the _Application_ can be moved to, can use it to move the _Application_. However, if there is an _Approval Task_ present in the _Project Domain_, you need approval before it can be moved to the next _Life Cycle Sub-Domain_ as designated by the _Approval Task_. - -If a _User_ does not have access to the _Move Task_, that _User_ can make a _Request Task_. Then a _User_ with access to the _Request_ and _Move Tasks_ can grant access to the _Move Task_. The _Approval Task_ also designates which _Life Cycle Sub-Domain_ the _Application_ can be moved to, so that in order to move an _Application_, both the _Approval_ and _Move Tasks_ must designate the same destination _Life Cycle Sub-Domain_. - -If an _Application_ has been approved by a _User_ with access to the _Approval Task_, it will appear in the boxes under the _Delivery Pipeline_ tab and will be shown with a green checkmark, and the _Application_ can then be moved to the designated _Life Cycle Sub-Domain_. If it has been rejected, it will be represented with a red 'X,' and it cannot be moved. - -An _Application_ can be moved to another _Life Cycle Sub-Domain_ by right-clicking on the _Life Cycle Sub-Domain_ within the tree structure and then selecting the _Move Task_. Once it has been moved, it is represented with neither a checkbox or 'X.' These icons only work when moving forward. When moving backward through _Life Cycle Subdomains,_ there are no icons displayed in the boxes under the _Delivery Pipeline_ tab. - -If an _Application_ is deployed, it appears in one of the lower boxes which represents the _Environment_ it was deployed to, and the _Application_ no longer appears in the upper box titled _Undeployed Applications_. _Environments_ are stacked vertically under the _Life Cycle Subdomains_ in which they belong. - -Using Jenkins as an example, Jenkins performs a software build which creates a new artificat (container, binary, etc.). Jenkins then calls DeployHub and places its Build Number into DeployHub to be referenced during a subsequent deployment. (This appears in the target _Component's_ General tab within the Last Build Number field). Jenkins then puts the files into the _Repository_ that is referenced by the _Component Item(s)_ within the _Component_. As a separate operation, Jenkins calls DeployHub to perform the deployment by referencing the _Application_ that contains the _Component_. For **DeployHub Pro** users, Jenkins can also call a _Release_ that contains multiple _Applications_. diff --git a/content/en/userguide/pipeline/_index.md b/content/en/userguide/pipeline/_index.md deleted file mode 100644 index 23e05514..00000000 --- a/content/en/userguide/pipeline/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: "Pipeline" -linkTitle: "Pipeline" -weight: 70 -description: > - How to Add DeployHub into your Pipeline. ---- diff --git a/content/en/userguide/profeatures/2 Data Sources.md b/content/en/userguide/profeatures/2 Data Sources.md index fcb3c823..cd8ee087 100644 --- a/content/en/userguide/profeatures/2 Data Sources.md +++ b/content/en/userguide/profeatures/2 Data Sources.md @@ -7,26 +7,18 @@ description: > --- ## Intro to Data Sources -Connecting to external _Data Sources_ is a DeployHub Pro feature. If you are a DeployHub Team user, this option will not be visible. _Data Sources_ are used to acquire data from outside of DeployHub. The most common use for _Data Sources_ is for setting up integration with issue tracking systems such as Jira, Bugzilla and GitHub. If you are using DeployHub Pro, you can configure _Components_ with _Change Requests_. To do this, you will need to define a connection to the change request system. This can be done using _Data Sources_. - -You can also use a _Data Source_ for accessing LDAP or Active Directory information for _User_ logins. The _Data Source_ object communicates with various databases, HTTP servers, FTP servers, etc., and can be used to take advantage of this kind of information sharing. - -### _Data Source_ and _Credentials_ - -When accessing external data, a User Name and Password pair is often required. For this reason, you will first need to define a _Credential_ for your _Data Source_. See [Create Your Credentials](/userguide/first-steps/2-define-your-credentials/) for more information on defining a _Credential_ for your _Data Source_. +_Data Sources_ are used to connect to Jira, Bugzilla, and GitHub to track change request and LDAP and Active Directory for single sign-on. You will need to define a _Credential_ for these _Data Sources_ in order to login. See [Create Your Credentials](/userguide/first-steps/2-define-your-credentials/) for more information on defining a _Credential_ for your _Data Source_. ## The _Data Sources_ List View for Adding or Deleting -You will find _Data Sources_ under the Setup menu. Selecting _Data Sources_ will take you to a list of all _DataSources_ which you have access to. You can also use the Filter bar, represented by a funnel icon, to reorder your _Data Sources_ List View. You can filter the list view on _Data Sources_ and _Domains_. - -_Data Sources_ are defined to a _Domain_ and will be displayed based on your access to the _Domain_. +You will find _Data Sources_ under the Setup menu. Selecting _Data Sources_ will take you to a list of all _DataSources_ which you have access to. You can also use the Filter bar, represented by a funnel icon, to reorder your _Data Sources_ List View. You can filter the list view on _Data Sources_ and _Domains_. _Data Sources_ are defined to a _Domain_ and will be displayed based on your access to the _Domain_. The _Data Sources_ List View has the following Tabs. | Tab | Description | | --- | --- | |Refresh | Refreshes the browser. | -| Add | Allows you to Add a new _Data Sources_ of a particular type. | +| Add | Allows you to Add a new _Data Sources_ of the following types: | | Delete | Deletes the selected item. | From the _Data Source_ List View, double click on the _Data Source_ which you would like to view to see all Details. @@ -51,9 +43,13 @@ The following details are common to all _Data Sources_ types: |**Modified**| Auto generated date when the _Data Source_ was updated.| |**Credential**| The _Credential_ used to access the _Repository_ if required. | -## GitHub _Data Source_ Details +## Change Request _Data Sources_ -This _Data Source_ allows you to connect to GitHub to retrieve GitHub issues associated to your _Components_. +DeployHub supports GitHub, Jira and Bugzilla for tracking change request to _Applications_ and _Components_. For a complete description of the integration see [Tracking Jira, Bugzilla and GitHub Issues](/userguide/integrations/jira-bugzilla-and-git-issues/ ). + +### GitHub _Data Source_ Details + +This _Data Source_ allows you to connect to GitHub to retrieve GitHub issues associated to your _Components_ or _Applications_. You will need to define a unique _Data Source_ for each repository that needs to be connected to your _Components_ or _Applications_. | Field | Description | | --- | --- | @@ -67,8 +63,9 @@ This _Data Source_ allows you to connect to GitHub to retrieve GitHub issues ass |**Repository Encrypted**| Select the box to indicate the Git Repository should be hidden in the database.| |**Repository Override**|Select the box if the Git Repository can be changed.| -## Jira _Data Source_ Details -This _Data Source_ allows you to connect to Jira to retrieve Jira issues associated to your _Components_. +### Jira _Data Source_ Details + +This _Data Source_ allows you to connect to Jira to retrieve Jira issues associated to your _Components_ or _Applications_. You will need to define a unique _Data Source_ for each Project Key that needs to be connected to your _Components_ or _Applications_. | Field | Description | | --- | --- | @@ -85,9 +82,9 @@ This _Data Source_ allows you to connect to Jira to retrieve Jira issues associa |**Server Encrypted**| Select the box to indicate the Jira Server should be hidden in the database.| |**Server Override**|Select the box if the Jira Server can be changed.| -## Bugzilla _Data Source_ Details +### Bugzilla _Data Source_ Details -This _Data Source_ allows you to connect to Bugzilla to retrieve Bugzilla issues associated to your _Components_. +This _Data Source_ allows you to connect to Bugzilla to retrieve Bugzilla issues associated to your _Components_ or _Applications_. You will need to define a unique _Data Source_ for each Product that needs to be connected to your _Components_ or _Applications_. | Field | Description | | --- | --- | diff --git a/content/en/userguide/profeatures/5 Application Releases.md b/content/en/userguide/profeatures/5 Application Releases.md index 6ee47e32..14191f55 100644 --- a/content/en/userguide/profeatures/5 Application Releases.md +++ b/content/en/userguide/profeatures/5 Application Releases.md @@ -1,19 +1,17 @@ --- -title: "Release Trains" -linkTitle: "Release Trains" +title: "Creating Releases" +linkTitle: "Creating Releases" weight: 80 description: > - Deploying Groups of Applications. + Using _Releases_ to manage many _Applications_ in a single deployment. --- -## Release Trains +## Intro to Releases - A _Release_ manages the progression and deployment of multiple _Applications_ together. _Releases_ and _Release Versions_ (DeployHub Pro only) are collections of one or more _Applications_ that are managed as a unit due to their interdependencies. _Releases_ are only available in DeployHub Pro. - -Like _Applications_ and _Components_, _Releases_ are versioned each time they are deployed. A _Release Base Version_ is the initial version and acts as a model for subsequent _Release Versions_. + A _Release_ manages the progression and deployment of multiple _Applications_ together. _Releases_ and _Release Versions_ are a DeployHub Pro feature. _Releases_ and _Release Versions_ are collections of one or more _Applications_ that are managed as a unit due to their interdependencies. This is sometimes referred to as a "Release Train." Like _Applications_ and _Components_, _Releases_ are versioned each time they are deployed. A _Release Base Version_ is the initial version and acts as a model for subsequent _Release Versions_. ## The _Release_ List View for Adding or Deleting -From the _Release_ menu option to the left of the DeployHub main panel, you will be taken to a list of all _Release Base Versions_ and _Release Versions_ to which you have access. There is a row for every _Environment_ to which the _Release Base Version_ or _Release Version_ has been deployed. For this reason, you will see multiple entries for the same _Release_ if it has been deployed to multiple _Environments_. +Use the _Release_ List View accessible from the left hand _Release_ menu option. This will take you to a list of all _Release Base Versions_ and _Release Versions_ to which you have access. There is a row for every _Environment_ to which the _Release Base Version_ or _Release Version_ has been deployed. For this reason, you will see multiple entries for the same _Release_ if it has been deployed to multiple _Environments_. The list view is organized on the following columns: @@ -44,32 +42,27 @@ The _Release_ List View has the following Tabs. | Tab | Description | | --- | --- | -| Refresh | Refreshes the browser. | -| Add Base | Allows you to Add a new _Release Base Version_. | -| Add Version | Creates a copy of the selected _Release_ in the list, creating a new _Release Version_. | -| Delete | Deletes the selected item. However, you must delete the _Release_ starting from the newest to the oldest. The _Release Base Version_ would be deleted last. Sorting by "Version" gives you the order. | -| Tasks | Displays all _Release_ Tasks defined to this _Domain_ and available for the selected Item. See [Tasks](/userguide/first-steps/2-defining-domains/#tasks) for more information. | -| List | Takes you back to the List View if you have been in the Map View. | +| **Refresh** | Refreshes the browser. | +| **Add Base** | Allows you to Add a new _Release Base Version_. | +| **Add Version** | Creates a copy of the selected _Release_ in the list, creating a new _Release Version_. | +| **Delete** | Deletes the selected item. However, you must delete the _Release_ starting from the newest to the oldest. The _Release Base Version_ would be deleted last. Sorting by "Version" gives you the order. | +| **Tasks** | Displays all _Release_ Tasks defined to this _Domain_ and available for the selected Item. See [Tasks](/userguide/first-steps/2-defining-domains/#tasks) for more information. | ## Viewing and Editing with the _Release_ Dashboard -The Dashboard view displays all information related to a specific _Release Base Version_ or _Release Version_. The Dashboard view has two additional tab options - Package Components and Versions. Below are the Details for an _Release_. +The Dashboard view displays all information related to a specific _Release Base Version_ or _Release Version_. Below are the Details for a _Release_. | Details | Description | | --- | --- | -|Full Domain | The fully qualified path of the _Domain_ that the _Release_ is to be associated, showing all parent _Domains_. | -|Name | The Name of your _Release_. | -|Owner Type| Owned by a User or Group. | -|Owner | Name of User or Group. | -|Summary | Description of the _Release_. | -|Created | Auto generated based on the date the _Release_ was added. | -|Modified | Auto generated based on the date the _Release_ was updated. | -|Change Request DataSource | DeployHub Pro Option - Establishes the Change Request system for the _Release_. A Change Request Data Source must be pre-defined for this field to be used. | -Pre-Action| An action that should be executed prior to the deployment of the _Release_.| -Post-Action| An action that should be executed at the completion of the _Release_ deployment.| -Custom Action | Overrides any Pre or Post Actions, such as calling an external solutions such as Helm.| -Successful Deployment Template | The template that should be used for success notifications. | -Failed Deployment Template| The template that should be used for failure notifications.| +|**Full Domain** | The fully qualified path of the _Domain_ that the _Release_ is to be associated, showing all parent _Domains_. | +|**Name** | The Name of your _Release_. | +|**Owner Type**| Owned by a User or Group. | +|**Owner** | Name of User or Group. | +|**Summary** | Description of the _Release_. | +|**Created** | Auto generated based on the date the _Release_ was added. | +|**Modified** | Auto generated based on the date the _Release_ was updated. | +|**Successful Deployment Template** | The template that should be used for success notifications. | +|**Failed Deployment Template**| The template that should be used for failure notifications.| ### Assigned Applications @@ -103,13 +96,7 @@ The Access Section allows _Users_ within designated _Groups_ to update or view t | **Deploy** | This allows any _User_ that belongs to any _Group_ in this list to deploy the _Application_. This is further restricted based on the Access defined at the _Environment_ level. | -### Change Request - -The Change Request section, available for DeployHub Pro users, shows enhancement requests and bugs for a selected _Application_ that your _Release_ consumes. You must have a "Change Request" Data Source defined in your General settings in order to see Change Requests. Change Request Data Sources can be connected to several popular bug tracking systems, including Bugzilla, GitHub, and Jira. To setup your Change Request see [Managing Data Sources](/userguide/customizations/2-data-sources/). - -Select the "+Add Change Request to this Version" to assign a Change Request to the _Release_. This will display all the Change Requests (Enhancements, Bugs, etc.) from the assigned Data Source in the resulting Select Bug Record pop up window, and one or more of these can be assigned to the _Release_ by clicking on the box to the left of each CR ID field. - -The lower section contains a list of Change Requests with the fields CR ID, Title, and Status. Clicking on the CR ID takes the User to a new tab in the browser that contains the source of the Change Request. For instance, if the _Release_ has a Change Request Data Source of the type GitHub, clicking on the CR ID field for a Change Request will open a tab with the bug or enhancement request within github.com, allowing the User the ability to update, close, or read about it in detail. The Title field holds the title of the Change Request within the bug tracking system. The various bug tracking systems used by DeployHub have their own statuses. Bugzilla for instance, has statuses such as New, Unconfirmed, Assigned, etc. DeployHub interprets these as either 'open' or 'closed’ and displays them in the Status field with a gold or dark gray background respectively. +{{% include "userguide/reusable/ChangeRequest.md" %}} ## Planner Tab diff --git a/content/en/userguide/profeatures/5 Change Requests.md b/content/en/userguide/profeatures/5 Change Requests.md deleted file mode 100644 index 444086d9..00000000 --- a/content/en/userguide/profeatures/5 Change Requests.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "Change Request" -linkTitle: "Change Request" -weight: 82 -description: > - Tracking Change Request. ---- -## Change Request - -The _Change Request_ tab (DeployHub Pro only) shows enhancement requests and bugs for a selected _Component_ for several popular bug tracking systems, including Bugzilla, GitHub, and Jira. - -External bug tracking systems are represented in DeployHub as a Data Source. The _Gener_al tab for the _Component_ allows for the selection and assignment of a _Data Source_ to the _Component_. _Change Request_s can then be assigned to the _Component_ in the _Change Request_s tab by clicking on the plus '+' icon in the upper right. This will display all the _Change Request_s (Enhancements, Bugs, etc.) from the assigned _Data Source_ in the resulting Select Bug Record pop up window, and one or more of these can be assigned to the _Component_ by clicking on the box to the left of each CR ID field. - -The _Change Request_ tab contains two sections. The upper section is titled CR Opened/Closed over Time, which contains a burndown chart showing all the _Change Request_s for the _Component_. A Calendar runs across the top to show when _Change Request_s were opened and closed. _Change Request_s are shown in the horizontal area below, with open _Change Request_s shown in light yellow, while closed are shown in dark gray. Each line represents a _Change Request_, which begins with the date that it was added to the _Component_. The area turns dark gray at the point of the Calendar where the _Change Request_ was closed. Using the scrolling device on the User's mouse or trackpad causes the entire area to expand and contract which, along with the ability to scroll back and forth via clicking and dragging, allows the User to easily view the entire Release Plan from beginning to end, in detail, while using the Calendar along the top as a reference. The numbers along the left side represent the number of _Change Request_s. This will adjust vertically to fit the total number of _Change Request_s for the _Component_. This can be adjusted further with the User's mouse or trackpad. - -The lower section contains a list of _Change Request_s with the fields CR ID, Title, and Status. Clicking on the CR ID takes the User to a new tab in the browser that contains the source of the _Change Request_. For instance, if the _Component_ has a _Change Request__Data Source_ of the type GitHub, clicking on the CR ID field for a _Change Request_ will open a tab with the bug or enhancement request within github.com, allowing the User the ability to update, close, or read about it in detail. The Title field holds the title of the _Change Request_ within the bug tracking system. The various bug tracking systems used by DeployHub have their own statuses. Bugzilla for instance, has statuses such as New, Unconfirmed, Assigned, etc. DeployHub interprets these as either 'open' or 'closed' and displays them in the Status field with a gold or dark gray background respectively. diff --git a/content/en/userguide/reusable/ChangeRequest.md b/content/en/userguide/reusable/ChangeRequest.md new file mode 100644 index 00000000..e770d968 --- /dev/null +++ b/content/en/userguide/reusable/ChangeRequest.md @@ -0,0 +1,10 @@ +### DeployHub Pro Change Requests + +The integration of Change Request systems are supported in DeployHub through the use of a _Data Source_. To integrate Change Request you must first define a Change Request _Data Source_ from the _Data Source_ Dashboard. Once created, you will be able to select the _Data Source_ from the General Details "Change Request _Data Source_" field of your _Application_ and/or _Component_. When you have a Change Request _Data Source_ defined, you can add issue tickets using the Change Request section of the _Application_ or _Component_ Dashboards. + +#### Creating Change Request _Data Sources_ +Jira, Bugzilla and GitHub are represented in DeployHub as _Data Source_ Types. Because a _Data Source_ is associated to a specific _Component_ or _Application_ you will need to map a unique _Data Source_ for each system's repository (Organization, Repository, Product, Project Key) where you are tracking the _Component_ or _Application_. In a traditional release process, a _Component_ and _Application's_ repository may be the same. Because microservices are often managed in their own repositories, you may need to define a _Data Source_ for each of your microservice _Components_. For more on creating a Change Request _Data Source_ see [Managing Data Sources](/userguide/profeatures/2-data-sources/). + +Change Request that are tracked at the _Component_ level are rolled up to the _Application_ level. All change request associated to _Components_ and _Applications_ are rolled up to the _Release_. + +Once connected, the Change Request Section for the _Component_ and the _Application_ shows all Change Request manually added. If a _Data Source_ has not been assigned, you will see a message "No Change Request Data Source has been setup." Once setup, you can use the '+Add' option to associate specific change request to the _Component_ or _Application_. Selecting +Add will create a new row in the table with a drop down list box. This drop down will contain all change request retrieved by the _Data Source_. Select the Change Request and use the Save option to commit the new row to the table. Use the Edit option to switch a Change Request, or Delete to remove a Change Request. diff --git a/content/en/userguide/reusable/LDAP-DataSource.md b/content/en/userguide/reusable/LDAP-DataSource.md index 2dd70dc0..2b8fe2a3 100644 --- a/content/en/userguide/reusable/LDAP-DataSource.md +++ b/content/en/userguide/reusable/LDAP-DataSource.md @@ -1,8 +1,7 @@ -## LDAP and Active Directory Integration +## Using a LDAP or Active Directory _Data Source_ for Single Sign-on DeployHub allows you to use LDAP or Active Directory to manage your _User_ logins. Create an LDAP _Data Source_ to access an LDAP database and use the information stored to gain access to DeployHub. It also populates the _Users_ General tab with Real Name and Email, which it gets from the LDAP database. When you define a _User_, you associate the LDAP authentication method. At login, DeployHub checks the User's authentication method to determine if LDAP or Active Directory should be used. - ### Creating a LDAP or Active Directory _Data Source_ diff --git a/content/en/userguide/reusable/Model Success.md b/content/en/userguide/reusable/Model Success.md index 835d1c2f..9003061d 100644 --- a/content/en/userguide/reusable/Model Success.md +++ b/content/en/userguide/reusable/Model Success.md @@ -5,4 +5,4 @@ This Object contains the success/failed return code and an error message. | Name | Type | Boolean Description| Required | | ---- | ---- | ----------- | -------- | | success | boolean | Success or Failure. | Yes | -| error | string | Error message returned from API. | No | +| error | string | Error message returned from API. | No | \ No newline at end of file diff --git a/content/en/userguide/pipeline/2 Define Your Build Engines.md b/content/en/userguide/save/2 Define Your Build Engines.new similarity index 100% rename from content/en/userguide/pipeline/2 Define Your Build Engines.md rename to content/en/userguide/save/2 Define Your Build Engines.new diff --git a/content/en/userguide/pipeline/BuildJobs.md b/content/en/userguide/save/BuildJobs.md similarity index 100% rename from content/en/userguide/pipeline/BuildJobs.md rename to content/en/userguide/save/BuildJobs.md