SDLC Application Deployment

tip

Role required: admin.

To deploy the SLDC application, complete the following steps:

1. Install the SLDC application.
2. (optional) Install the SDLC-ITSM integration package.
3. (optional) Deploy the demo data.

Deploy full version

---

To install the SDLC application, install the [SDLC] X.X.X full.sop SOP file, where X.X.X is the application version.

Install updates

---

When updating the installed SDLC application, additional actions may be necessary. You can find the required information about the installation of a specific version in the relevant article of the Release Notes section.

tip

Role required: admin

Install all versions and patches in order. When updating the installed SDLC application, additional actions may be necessary. You can find the required information about the installation of a specific version in one of the relevant tabs below.

For the versions not mentioned below, no additional actions are required. To update your instance to them, install the [SDLC] X.X.X.sop, where X.X.X stands for the number of the next version after the one currently installed on your instance. Repeat if you need to update your instance to more than one version.

1.8.0

Update version 1.7.0 to version 1.8.0

To install the updates included in the SDLC version 1.8.0, import the SOP-file with the application update. After that, perform a migration to the new version. To do so, run the Migration script for SDLC 1.8.0 version script located at the {your instance URL}/record/sys_script/175672220206187254 address.

The migration includes three major stages:

1. The main stage of the migration during which the majority of changes are made.
2. The launch of the SDLC.1.8.0.task_fields_feature_states system event for the migration.
3. The launch of the SDLC.migration_1.8.0.task_state_update system event for the migration.

While the script is running, success or error messages are added to the Main Log, if they occur on any of the migration stages. When the script execution and corresponding system events are completed, a record describing the migration results is added to the Main Log.

If errors occur, resolve them manually. You do not need to run the script again after resolving the errors, but you can if necessary. For instance, if you made some of the columns non-mandatory for the resolution of the errors, and these columns need to be updated with the script.

Main stage of the migration

The list of changes that take place during the main stage of the migration:

1. The Column Style Rule (sys_style_rule_column) table records created for the state choice options with the canceled and released Value are deleted for the SDLC Task (pda_backlog_item) table and its child tables.
2. The state choice options with the canceled and released Value are deleted from the Choice Option (sys_choice) table for the SDLC Task (pda_backlog_item) table and its child tables.
3. The Canceled and Released labels in Russian are added to the Form Label (sys_color_table_label) table for the SDLC Task (pda_backlog_item) table and its child tables.
4. The State model field is completed in the records of the Task Type (pda_task_type) table: a state model the Table of which matches the table whose State options are applied for the task type is specified. This could be the task type table, if you have overridden the state options, or one of the parent tables: SDLC Task (pda_backlog_item) or Task (task). If there is no such state model, the field remains empty. If there is more than one such state model, the record created earlier is specified.
5. The State Model in Project (pda_state_model_project) records are created for each project and the task types added to them. The model whose Condition contains "Project equals the current project" and "Task type equals the current task type" is specified.
6. The Board Column (board_column) records are updated:
   • All column records are recreated. Custom configuration of the columns is overridden by default values.
   • The columns for the "out-of-the-box" Backlog, Development, Review, Testing, Done states, and the states with matching choice option Value are created Active. The columns for other states, including the custom ones, are created inactive.
   • If there are state options with identical Value, only one column is created for them.

System events

The system events that update records of the SDLC Task (pda_backlog_item) table and its child tables during the migration:

1. SDLC.1.8.0.task_fields_feature_states – the event:

   • completes the Task type field on the task forms with the task type that matches the record's table,

   • changes the display name of all tasks according to the new template {number} + [{pda_project_code}] + {subject},

   • changes the states of existing features according to the new state model:

     State before migration	State after migration
     New	Funnel
     Development, Review, Testing	Implementation
     Done	Completed

2. SDLC.migration_1.8.0.task_state_update – if the task is in the Canceled or Released state, the event changes its state to the previous one according to the SDLC Task State Change (pda_task_state_history) table and marks it as Canceled or Released. If the previous history record is not found, the record state is set to --None--.

info

The migration system events process a hundred records per iteration. If there are more than a hundred records in the SDLC Task (pda_backlog_item) table and its child tables on the instance, the events are launched automatically until they process all the records.

Possible errors

Main stage of the migration

Error: [SDLC Migration 1.8.0] Errors while running the migration:

• Failed to {the_action_performed_by_the_function} in the function {function_name}:
  • {Error}. ({record_id})

Solution:

1. If State models could not be specified for task types, create state models for them and specify them on the task type forms.
2. If State Models in Project could not be created or were created incorrectly, add state model in project records manually or complete empty fields of the created state models in project.
3. If board columns could not be created or were created incorrectly, check the configuration of State choice options, and then check the configuration of the created columns.

SDLC.1.8.0.task_fields_feature_states system event

Error: [SDLC migration 1.8.0] Errors while updating Task type, Display name, or State for features in records:

• {Error}. ({record_id})

Solution: The error might occur if the mandatory fields updated by the event are empty in the processed records, or some of the values that must be unique are repeated in those fields. Open the forms of such records and fill in or change the values of those fields manually. You can also make those fields non-mandatory for the migration as a workaround solution.

SDLC.migration_1.8.0.task_state_update system event

Error: [SDLC migration 1.8.0] Errors while updating State in records:

• {Error}. ({record_id})

Solution:

1. If the Released checkbox could not be selected for tasks, change their state to the previous one using inline editing, and specify a released release that includes them.
2. If the Canceled checkbox could not be selected for tasks, open their forms, change their state to the previous one using inline editing, and cancel them manually in the burger menu .

1.6.0

Update version 1.5.2 to version 1.6.0

In this update, we have added the configuration of cards filtering on the boards. For it to work, you need to launch a script that completes the Table for the filter (pda_table_id) field for existing boards. We have also updated the demo data but you do not need to reinstall them: launching the script as described below will fix the demo data from the previous versions.

If there are task boards on your instance, perform the following actions after the 1.6.0 update:

1. Navigate to System Settings → Server Scripts.
2. Open the Mirgation script for table for filter script record form located at {your instance URL}/record/sys_script/174584256514191079.
3. Click Run at the bottom of the form.

These actions must be performed only once and are not required during the subsequent updates of the application.

1.1.3

Update version 1.1.2 to version 1.1.3

This update has fixed incorrect system name of a sprint state.

If the Sprint (pda_sprint) table is not empty, perform the following actions after the 1.1.3 update:

1. Import the [SDLC]_STR0003361_Fix_state_for_sprint.sop SOP file.
2. Navigate to System Settings → Server Scripts.
3. Open the Fix incorrect state for sprint script record form.
4. Click Run at the bottom of the form.

These actions must be performed only once and are not required during the subsequent updates of the application.

1.2.1

Update version 1.2.0 to version 1.2.1

This update has introduced the SDLC Task State Change table that stores data on task state changes. The table is populated automatically from the moment the application is updated to the new version. To add the history of task state changes that occurred prior to the 1.2.1 update, complete the following steps immediately after the update is finished:

Create history for existing tasks

1. Import the [SDLC]_STR0003993_Create_SDLC_Task_State_Change_Records.sop SOP file.
2. Navigate to System Settings → Server Scripts.
3. Open the Create history records for tasks script record form.
4. Click Run at the bottom of the form.

Use the records in the Main Log (sys_log) table to monitore the progress of script execution. A record is made in the table after every 500 processed task records. When all task records are processed, the record "Migration script finished" appears in the Main Log.

Depending on the number of records in the SDLC Task table, the script can take some time to be completed. The estimated time to process 10,000 records is 25–30 minutes.

These steps only need to be performed once and are not required during the subsequent updates of the application.

1.3.1

Update version 1.3.0 to version 1.3.1

This patch expands the logic of specifying spent time from the task forms and from the task preview window on project boards. Now when a user specifies the time spent on a task, the system takes into account the limits introduced in version 1.1.1 of the Work and Time Management (WTM) application.

To update the existing time entries in accordance with the changes in the WTM application, complete the following steps:

warning

Before making changes, ensure that the SDLC application is selected in the Admin Preferences of the sidebar.

1. Import the [SDLC]_STR0004547_Update_time_spent_in_SDLC_Tasks_and_Timesheets.sop SOP file.
2. Navigate to System Scheduler → Scheduled Scripts.
3. Open the [SDLC] Update time spent in SDLC Tasks and Timesheets script form.
4. Select the Active checkbox.
5. Select the convenient date and time in the Run date and time field.
6. Click Save or Save and exit to apply the changes.

The script will run at the specified time and update the values of the Total time spent (pda_total_time_spent) in the task records and the records of the Timesheet (wtm_timesheet) table in accordance with the Timecards (wtm_timecard). Use the Main Log (sys_log) to monitor the progress of script execution.

Depending on the number of records, the script can take some time to be completed. The estimated time to process 10,000 records of the SDLC Task table and 1000 records of the Timesheet table is 10 minutes.

These steps only need to be performed once and are not required during the subsequent updates of the application.

Install the SDLC-ITSM integration package

If the ITSM application is installed on your instance and you need to connect it to the SDLC application, install the [SDLC] SDLC.1.2.0_ITSM.1.12.1.sop file and configure the SDLC-ITSM integration. You only need to configure this package once. The data will be preserved at the future updates of the application.

info

Supported application versions:

• ITSM 1.12.1
• SDLC 1.2.0

Deploy the demo data

The SDLC demonstration data package is designed to help a user learn the funcionality and overall logic of the application. The demonstration data include examples of records for all major application tables, as well as records in the Simple Application tables, such as employees with the configured roles. You can use them to explore the appication role system.

Several projects with configured infrastructure will be added to your instance if you upload the demo data. This includes pre-configured boards, examples of products, product modules, tasks of all types and project members.

note

The demo data is only available in Russian at the moment.

The file with the demo data is provided with the application. To deploy the demo data on your instance, complete the following steps:

1. Ensure that SDLC application is installed on your instance. Click the icon in the right upper corner of the screen to open the Preferences menu. Check if the SDLC option is present in the Application drop-down list.
2. Import the JSON file with the demo data.

Records list

---

Demo data (SDLC entities)

• 7 projects (2 projects that use the SCRUM approach and 5 that use the KANBAN approach). There are six products dedicated to the product development, and one is not related to a product. A task board of the corresponding type is available for each project.
• 32 project members (some employees participate in more than one project)
• 5 products
• 18 product modules
• 6 sprints
• 2 releases
• 6 additional attributes for two boards
• 2 areas for two boards
• 12 badges for three boards
• 42 columns for all boards
• 4 swimlanes for three boards
• 6 swimlane rules
• 14 color markers for five boards
• 81 tasks:
  • 7 epics
  • 9 features
  • 10 defects
  • 17 user stories
  • 32 general tasks
  • 5 subtasks

Demo data (Simple Application entities)

• 13 employees with pda_user role
• 1 employee with pda_user, pda_admin roles
• 1 company
• 1 location