by Nick Entin – Software Engineering Director, Polarion ALM, Siemens PLM<\/em><\/p>\n\n\n\n
A behind-the-scene look at the development of Polarion.<\/h2>\n\n\n\n
In this 2 part blog post series, we will take a deep dive into Polarion R&D’s processes and best practices in regards to DevOps.
Many years back, I wrote a set of \u201cPolarion Goes SCRUM\u201d articles. At the time, the Agile methodology was not yet mainstream, and the use of tools like Application Lifecycle Management (ALM) was not common practice. Since then, we\u2019ve learned how to leverage our Polarion expertise and ALM experience to optimize our processes and best practices. <\/p>\n\n\n\n
In part one we will focus on the transition of the R&D Team to DevOps.<\/p>\n\n\n\n
In part two we continue where we will focus on how we “drink our champagne”, how we utilize Polarion’s capabilities to build Polarion for you!<\/p>\n\n\n\n
Background <\/strong><\/h3>\n\n\n\n
The term ALM has started to lose its luster of late. Analysts have even begun to replace it with phrases like EAPT (Enterprise Agile Planning Tools) and SLM (Software Lifecycle Management). This has reduced the traditional domain of the more generic ALM. <\/p>\n\n\n\n
There\u2019s a lot of talk about how DevOps isn\u2019t considered a native component of ALM. Some go as far as suggesting that there\u2019s no need for ALM at all and everything can be done via popular DevOps tools like GitLab or GitHub. <\/p>\n\n\n\n
In my opinion, DevOps is a natural component of ALM and it\u2019s just a matter of how well an ALM tool implements the DevOps domain and integrates with its established solutions. <\/p>\n\n\n\n
I\u2019ll outline several scenarios we\u2019ve addressed internally in this area that you can easily implement in your production environment today.<\/p>\n\n\n\n
The Scenario<\/strong><\/h3>\n\n\n\n
Let\u2019s start with the\/our problem statement<\/p>\n\n\n\n
We have: <\/strong><\/p>\n\n\n\n
A complex product. <\/li>
The Release Cadence is known in advance and must be followed. <\/li>
Every release should have functional and quality increments. (Substantial enough to be of value to our customers.) <\/li>
A continuous demand to not only change or adopt a new architecture but also to update the UI. (So that it aligns with other Siemens products and implements the best UI practices and components to maximize usability.) A bunch of Scrum teams integrate different components to the product line and must continually be aware of crossover dependencies. <\/li>
Cross-product maintenance tasks (improvements, defect fixing, performance and scalability improvements) that typically affect many areas of the application. They are not the responsibility of a single team, and their impact on the codebase can be far-reaching. <\/li>
Continuously changing prioritizations (new\/funded projects, customer escalations and estimate changes) that may lead backlog reprioritization, etc. <\/li><\/ul>\n\n\n\n
We need: <\/strong><\/p>\n\n\n\n
An infrastructure that allows several teams to work in parallel without disturbing each other, especially during the integration phases. <\/li>
The system should be able to track how the execution of multiple topics progresses. (For both reporting and synchronization purposes.) <\/li>
Each developed feature should be thoroughly tested. (First locally by the development team, then again after integration. This ensures the general stability of the release and eliminates possible regressions.) <\/li>
Multi-level integration of the source code should still provide traceability between tasks\/requirements and the code. (Enables the code review process and ensures that all changes can be audited.) <\/li>
A useable collaboration platform so that teams can effectively consult with each other, Support and Services. It should help facilitate: <\/li><\/ul>\n\n\n\n
Discussion threads with an easy way to find notes and conclusions. <\/li>
Able to request and receive specific expertise from the entire community. <\/li>
Customer-on-site support. (For us, it typically means having a Product Manager and\/or Product Owner continuously available for ad-hoc consultancy.) <\/li>
The possibility to report the progress continuously and without much time overhead. <\/li><\/ul>\n\n\n\n
<\/p>\n\n\n\n
The Big Picture <\/strong><\/h3>\n\n\n\nPolarion DevOps the big picture<\/figcaption><\/figure>\n\n\n\n
Artifacts (requirement documents, stories, tasks, defects, tests, etc.) lifecycle management, including the full traceability of changes and workflow as the standard operating procedure (SOP) driver. <\/li>
Estimation, prioritization and planning <\/li><\/ul>\n\n\n\n
GitLab \u2013 build management and a Continuous Integration, Continuous Delivery\/Deployment (CI\/CD)infrastructure: <\/h5>\n\n\n\n
Branching and merging <\/li>
Compiling and building <\/li>
Test automation execution <\/li><\/ul>\n\n\n\n
Hardware and Software virtualization: <\/h5>\n\n\n\n
A set of servers and containers for local and global test environments. <\/li>
Team-specific test servers <\/li>
Version-specific reference servers. (To reference, for example, how a feature worked in a specific past product version or to replicate an issue.) <\/li>
Monitoring, auto deployment, etc. <\/li><\/ul>\n\n\n\n
Development\/engineering tools. (Here\u2019s just a few for a reference): <\/h5>\n\n\n\n
A quick guide to the terminology and main artifacts of our product life cycle. <\/p>\n\n\n\nDevOps Lifecycle<\/figcaption><\/figure>\n\n\n\n
Business Requirements <\/h5>\n\n\n\n
Every good product comes with innovative ideas and proposals on how to address existing or projected customer needs. These ideas come from a variety of sources. From creative team members who think of something completely new, sales teams who collect data and requirements from customers, or Service colleagues who know how to improve existing functionality or implement established solutions in the real world. <\/p>\n\n\n\n
The Business Requirements are typically represented by a set of documents describing the problem statement and a proposal of what needs to be addressed. <\/p>\n\n\n\n
![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/4\/2021\/07\/polarion-devops-big-picture.png\")
![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/4\/2021\/07\/polarion-goes-devops-lifecycle.png\")