{"id":3439,"date":"2021-08-13T05:41:10","date_gmt":"2021-08-13T09:41:10","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/polarion\/?p=3439"},"modified":"2026-03-26T05:41:56","modified_gmt":"2026-03-26T09:41:56","slug":"part-2-polarions-rd-goes-devops","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/part-2-polarions-rd-goes-devops\/","title":{"rendered":"Part 2: Polarion\u2019s R&D Goes DevOps"},"content":{"rendered":"\n

Part 2: Polarion’s R&D Goes DevOps<\/h1>\n\n\n\n

by Nick Entin – Software Engineering Director, Polarion ALM, Siemens PLM<\/em><\/p>\n\n\n\n

In part two of the series, where we continue on how we “drink our champagne” within Polarion R&D and how we utilize Polarion’s capabilities to build Polarion for you!<\/p>\n\n\n\n

Let’s kick it off with how we do planning here at Siemens Polarion within Polarion.<\/p>\n\n\n\n

Planning <\/strong><\/h3>\n\n\n\n

While planning strategically, Capabilities are prioritized and assigned to their corresponding departments. There they are estimated and provided with the relevant Capacities to ensure their completion. <\/p>\n\n\n\n

\"Graphical<\/figure>\n\n\n\n

 (some pieces of the picture are blurred for business and GDPR reasons) <\/sub><\/p>\n\n\n\n

On the product\/project level, a plan may be distributed amongst Scrum teams to ensure that the work is distributed appropriately, and any required synchronization is identified. <\/p>\n\n\n\n

\"Table\n\nDescription<\/figure>\n\n\n\n

When the planning reaches the Scrum team level, Capabilities are broken down into Features then again into User Stories (Defects, Patches, or other relevant PBIs).  On each level, related activities need to be planned, and their progress evaluated over time. For example, a Capability must be aligned with the capacity of the assigned team(s), Features, and planned so that they can be delivered to a customer by the target date. Teams should easily be able to assess a User Story\u2019s level of complexity based on the number of Story Points assigned to it.  <\/p>\n\n\n\n

Relevant activities for an upcoming PI for a Scrum Team:<\/strong> <\/p>\n\n\n\n

\"Graphical<\/figure>\n\n\n\n

The corresponding execution progress can be monitored via a Burn Down Chart: <\/strong><\/p>\n\n\n\n

\"Chart\n\nDescription<\/figure>\n\n\n\n

  <\/p>\n\n\n\n

The graph above reflects our level of agility. Even after starting a PI,  after all planning and estimations, the estimates continue to change. (And the change is usually a rise.)  The gap between the remaining estimate and the ideal progress is expected because we only burn points after the planned PBIs are completely done. (This usually takes a little time before it\u2019s reflected in the Burn Down Chart.) <\/p>\n\n\n\n

Possible Burn Down Chart<\/strong>4<\/sup><\/strong>:<\/strong> <\/p>\n\n\n\n

\"Image<\/figure>\n\n\n\n

And for a concrete Sprint:<\/strong> <\/p>\n\n\n\n

\"Graphical<\/figure>\n\n\n\n

Software Development Lifecycle (SDLC) <\/strong><\/h3>\n\n\n\n

I will not touch on all aspects of the SDLC. I am simply trying to give an overall picture of the tool chain we use and how we guide our process through it. <\/p>\n\n\n\n

Most of Polarion\u2019s code is written in Java so we use the following Integrated Development Environments (IDE) to code for it: Eclipse, IntelliJ and others. <\/p>\n\n\n\n

These IDEs are well integrated with the Revision Control Systems (RCS) we use GitLab and allow for a lot of additional functions like static code analysis or the execution of automated tests directly on newly written code.  <\/p>\n\n\n\n

1. Source code branching and committing<\/strong> <\/h4>\n\n\n\n

One of our most important best practices is to only make changes to the code base when there\u2019s a compelling reason to do so. These changes are always done via a Project Backlog Increment (PBI). When a User Story or Defect transitions to \u201cIn Progress\u201d a GitLab branch is automatically created as part of the workflow.  
 
General PBI lifecycle:<\/strong> <\/p>\n\n\n\n

\"Diagram\n\nDescription<\/figure>\n\n\n\n

Polarion allows for the automation of these procedures by defining Workflow functions for the corresponding Work Item types:<\/p>\n\n\n\n

\"Graphical<\/figure>\n\n\n\n

 <\/p>\n\n\n\n

To improve collaboration, we also automatically create Slack notifications so that all Team members are informed of an item’s progress and can discuss issues and obstacles more organically in real-time. <\/p>\n\n\n\n

Slack interface:\u00a0<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

When a developer is ready to commit changes to a GitLab branch, they include the PBI’s Work Item ID in the Git commit message. (All changes are linked to the item that prompted them.) <\/p>\n\n\n\n

The system of IDs works a little differently in Polarion compared to other similar tools. The prefix identifies the project where the Work Item is stored. (\u201cDPP\u201d is our production Project). The second part then assigns a numeric identifier that\u2019s unique to the project. <\/p>\n\n\n\n

An example of commits tied to a specific Work Item:<\/strong> <\/p>\n\n\n\n

\"Graphical<\/figure>\n\n\n\n

Clicking on the Linked Revision will open the GitLab UI and display the changes made. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

This, together with the review of changes in GitLab, facilitates the Code Review process: <\/p>\n\n\n\n

\"Graphical<\/figure>\n\n\n\n

Commenting on a change starts a discussion. All discussions must be resolved before a PBI\u2019s status can be changed to \u201cReady for Merge\u201d.  <\/p>\n\n\n\n

The template for the \u201cReady for Merge Checklist\u201d:<\/strong> <\/p>\n\n\n\n

\"Graphical<\/figure>\n\n\n\n

For example, the populated table may look as follows:<\/strong> <\/p>\n\n\n\n

\"Graphical<\/figure>\n\n\n\n

Whenever an item is marked as \u201cReady to Merge\u201d, the responsible engineer can trigger a Merge pipeline. The steps are as follows: <\/p>\n\n\n\n