Branching is a valuable tool for testing teams, allowing them to create copies of projects (Branches) and work on them in parallel. This provides flexibility and agility, enabling multiple teams to focus on different features or releases without impacting each other.
ACCELQ offers comprehensive branching and merging capabilities within a codeless and functional paradigm. This means managing your test assets is straightforward, avoiding the complexities of external version control systems.
Key benefits:
- Branching flexibility: Create separate branches for different features, sprints, or releases. Teams can work independently without affecting each other's progress.
- Simplified merging: Merge changes from branches back to the master project easily when ready.
- Codeless approach: Manage test assets directly within ACCELQ, eliminating the need for external tools or coding knowledge.
- Functional version control: Track changes at the functional level (e.g., entire test cases, data sets), providing a clearer understanding of modifications.
- Automatic dependency management: When branching, dependencies between test assets are automatically bundled, ensuring consistency across branches.
- Improved collaboration: Teams can work confidently on separate branches knowing dependencies are handled.
ACCELQ's functional approach to version control differs from traditional file-based systems like GitHub, which track individual file changes.
By leveraging ACCELQ's branching and merging capabilities, testing teams can streamline their workflow, improve collaboration, and deliver high-quality software faster.
Creating a Branch
Creating a branch requires Tenant Admin privilege. When you create a branch from a project, you tag related test assets for merging at a later point.
- Login as Tenant Admin
- Navigate to Manage Projects tab
- Right-click required Project row or click on the row-level context menu
- Select Create Branch Project from the context menu
Once created, a newly listed branch works exactly like any other Project in your Tenant. For example, you can assign users and roles, update configuration, setup new test assets, etc. If a user is assigned multiple projects/branches, he/she can switch between these projects and branches seamlessly.
By default, a branch project inherits the same set of users and the same configuration as the parent project.
| Here is an example of how different projects may be related once you create branches and sub-branches. |
Updating test assets from related projects
In the typical course of test development for various application releases, you may create a branching hierarchy appropriate for your needs. From time to time, you may update the test assets in one project with those from another related project. For example, you may pull changes from a parent project or from one of the child projects.
Although ACCELQ provides an ability to pull changes between any two related projects (as in the figure above), it is most common to perform this activity between a project and its direct parent or a direct child.
A Project can be updated with changes from a related project either as a Project Admin or a Tenant Admin.
As a Project Admin, click on the context menu against the Branching Information section and select Pull changes from Related Project
Alternatively, as a Tenant Admin, navigate to the Manage Projects tab and right-click the project that needs to be updated.
Selecting the Project to Update from
Once you decide to update the project, you are prompted to select the project (Source project) from where the updates have to be pulled in.
You can select one of the child projects or the immediate parent project to pull changes from. You can also select any other related project in the entire hierarchy.
Merge Wizard
Merge Wizard guides you through the process of updating a project with a step-by-step review of test assets. Two separate (related) projects are involved in this process:
- Target Project: Is the project which is getting updated as part of this flow
- Source Project: Is the project from where the changes are pulled
It is important that you clearly differentiate these two projects during the merge/update process.
In the Merge wizard, you are reviewing the changes in the Source Project and accepting/rejecting to be pulled into the Target Project. Changes in the Source project are presented in comparison with the Target project with a two-column display of difference (diff-view).
Reviewing the changes
All the changes done in the Source Project are presented for review and to accept/reject into the Target Project. Note that you are reviewing the updates to the Source Project with an intent to accept (or reject) into the Target Project.
Changes happening in the Source Project are divided into modules and the review process moves from one module to the next, based on their order of dependency. For example, changes to Scenario are presented before the changes to the Action are presented, as the Scenarios depend on the Actions. Similarly, Element changes are presented after the Action changes due to the dependency order.
In a given module, you navigate through each change and accept/reject to move to the next item. Once all the items in a module are decided on, you can navigate to the next module and so on until the last module.
Categorization of changes
Changes in Source project are presented in 5 categories for each module:
- Modified: Set of entities that have changed in the Source project compared to the Target project. You may accept or reject these changes to the Target project.
- Added: Newly added entities in the Source project. You can choose to add these entities to the Target project or ignore them.
- Deleted: Deleted entities in the Source project. You can decide to either delete in the Target project also or to retain it as-is.
- Added: Auto Accepted: Explained in the dependency-analysis section below.
- Deleted: Auto Recovered: Explained in the dependency-analysis section below.
Across each of these categories, you can take bulk actions like Accept-All or Reject-All by clicking the "..." icon in the category header.
Dependency Analysis
ACCELQ's Test-Asset approach is built on core concepts of modularity and reusability, which means there is cross-utilization of test assets and supporting entities. As you make selections in one module, there may be some hard dependencies in the subsequent modules.
For example, based on the Scenarios selected to be added or accepted into the Target project, there may be a hard dependency on some of the newly added Actions from the Source project. When you are reviewing changes in Action module, this set of Actions becomes mandatory to copy to Target project. ACCELQ calculates such dependencies and automatically selects them in the Actions module. These Actions are placed in the Auto-Accepted/Auto-Recovered categories. You are not allowed to change these selections.
Dependency Alerts
When moving out from a module, a thorough analysis is performed to make sure the selections in this module are valid and sufficient. This avoids integrity issues when the final merge is submitted. In some occasions, there may be internal dependencies within a module such as an Action calling another Action. Depending on which modifications you accept to copy to Target project, there may be other Actions that need to be pulled in. You are prompted to add all such dependencies.
Granularity of change detection
Changes are tracked and presented at following module levels:
- Configuration changes
- Resource changes
- Test Suites (Automation & Manual)
- Scenarios
- Actions
- Contexts
- Elements
- Views
From the list above, you can notice that a change to an individual Element is tracked independently, rather than as a change to "Element Repository". User can make a decision to accept/reject changes at the level of an Element. This approach reduces the possibility of conflicting changes when you are working in a dynamic setup with multiple Sprint teams updating respective branches concurrently.
Handling Project Configuration changes
Configuration changes are handled gracefully to ensure there is no impact on the existing entities when configuration changes are applied to the Target project. Here is how different changes are handled in the merge process
- Status fields: Newly added status fields in the Source project are automatically carried over to the Target project, while any modifications are presented for a user-decision to accept/reject.
- Custom fields: Same as the status field values above. Additions are automatic, but modifications are presented for accept/reject. Applicable-modules for custom fields are consolidated between the Source and Target project.
- Execution Parameters: All the newly added parameters are automatically added while modifications are presented for accept/reject. All the list values and multi-select options are consolidated between the two projects.
- App Environments: Newly added environments are automatically added. Updates in the existing environments are presented for accept/reject.
In all the above cases, deletion of configuration items on the Source project are automatically rejected. If necessary, configuration items can be deleted from the Target project after the merge process.
Other configuration items such as Integrations, Notifications, General Settings, User Setup, etc. are not carried over to the Target project as part of the merge process.
Merging the Views
When comparing the Views in the Source project, the following options are presented for the newly added Views and deleted Views from the Source project.
- The first option for the newly-added-views makes sure only the minimum required Views are copied over the Target project, ensuring that the Target project is not cluttered with an overload of unnecessary Views. ACCELQ runs an algorithm to optimize the number of Views automatically. It is recommended to choose this option unless there are other reasons.
- The second option below copies over all the newly added Views from the Source project to the Target.
Similarly, for the Views that are deleted in the Source project, it is a good practice to delete them in the Target project unless they are needed for other test assets in the Target project. It is a good practice to purge unneeded Views.
Merge Conflicts
While reviewing the changes, specific attention must be paid if a Merge Conflict flag is displayed for a test asset in the diff-view. This flag indicates that the test asset has been updated in both the Source and Target projects independently (concurrently). So, if you are accepting the changes in the Source project to be copied over to Target, you may potentially end up losing the changes done in the Target project.
Carefully review the diff on both sides. If required, you may open these entities directly from the Merge wizard and make changes. You may refresh the diff-view by hovering on the name of the entity and clicking on the refresh icon.
Reviewing the Summary of merge operation
You can review the current status of update selections/rejections etc. by clicking on the Module dropdown in the left-nav. This brings up a summary of current selections, along with an ability to navigate back to one of the modules already completed.
You are also presented with this Summary screen just before the final confirmation button is clicked in the merge wizard. You can go back to any module for corrections and continue the progress.
Project Merge under Change Control
If change control (or version control) is enabled either on the Source or Target project, the following points must be considered. If possible, it is recommended to get all the entities checked-in on both the Source and Target projects before initiating a project update/merge.
Entity is checked-out on Target project
Since the entity is checked-out on the Target project, it cannot be overwritten. Consequently, if there is an Action or Scenario that you are reviewing in the merge wizard, Accept button is disabled.
If required, you can navigate to the entity on the Target project and release the check-out lock by either checking in or overriding. Simply refresh the entity in merge wizard after releasing the lock and accept the changes on Source project.
Entity is checked-out on Source project
If an Action or Scenario is checked-out on the Source project, the diff modal presents the base version and when you accept the changes to move to Target project, you are moving the base version. Checked-out user's version of the entity is not copied.
Viewing Update History
You can review update history either from the Project grid (Manage Projects, as a Tenant Admin) or in the Project Config home screen (as a Project Admin).
Comments
0 comments
Article is closed for comments.