Release Management - Workflow Procedure

APD

Hi,

I'm thinking of implementing a new Project Release Workflow.

1. Release part studios. (thereby all parts)
2. Update assemblies with released parts ("Update to latest" so feature tree shows the black triangles)
3. Release All Assemblies.
4. Update all parts and assembly drawings so that they show released parts and assemblies.
5. Release All drawings.

I've broken it down like this because doing everything from a single release candidate was troublesome.  I was having to fix to fix too many issues - drawings pending update, assembly errors, part errors, duplicate part numbers ("this part was previously released from another document" where the document has been copied).

Also the candidate dialog list becomes very long.  The two panes (left and right) do not quite line up (maybe just my Chromebook).  So by the time you get to the bottom of the list, the misalignment causes confusion as to which part you might be editing/releasing (exacerbated by the fact I'm using the auto-gen arbitrary part numbers. )

Using the above proposed sequence I can more systematically correct issues with the project and have all of the drawings in a single release candidate (step 5).

Would be interested in any feedback.

TimRice

Alexei_Pittowicz said:

...The two panes (left and right) do not quite line up (maybe just my Chromebook).  So by the time you get to the bottom of the list, the misalignment causes confusion as to which part you might be editing/releasing...

Please submit a support ticket with screenshot(s) of this behavior so we can take a look!

adrian_vlzkz

Hi @Alexei_Pittowicz, We where just talking to Onshape about this last week. The way I would expect a Release to behave is:

If you submit a Drawing and all it's corresponding reference as a candidate: one would expect that drawing to have a "Released" triangle as reference for the release of the components. 

The way Onshape does it you can basically release Rev A of a Drawing with all it's reference flagged as WIP and never released, which to me just seems wrong, or a very BAD practice in terms of Data Management.

michael_bromley

adrian_velazquez said:

Hi @Alexei_Pittowicz, We where just talking to Onshape about this last week. The way I would expect a Release to behave is:

If you submit a Drawing and all it's corresponding reference as a candidate: one would expect that drawing to have a "Released" triangle as reference for the release of the components. 

The way Onshape does it you can basically release Rev A of a Drawing with all it's reference flagged as WIP and never released, which to me just seems wrong, or a very BAD practice in terms of Data Management.

That is not exactly true because if you release a drawing it automatically includes the corresponding part or assembly.  Drawings carry with them the parts that they reference to ensure that you do not release a drawing of a WIP part.  Therefore if it is the WIP then it will revision that part/assembly as necessary.  On the contrary, if you update the version of the part/assembly in the drawing to a released version then when you go to release that drawing it will display the revision of the part/asm that is being referenced.

The issue lies in that as Alexei has pointed out it makes more sense to release in multiple stages to better capture the data.  I agree that a multiple stage release makes a little more sense, but is certainly cumbersome.

APD

TimRice said:

Please submit a support ticket with screenshot(s) of this behavior so we can take a look!

@TimRice (ticket: #153246) This was just a single drawing. The list grows as drawings are added to the candidate, as does the misalignment. As I've said, it could be just my Chromebook.

adrian_vlzkz

michael_bromley said:

That is not exactly true because if you release a drawing it automatically includes the corresponding part or assembly.  Drawings carry with them the parts that they reference to ensure that you do not release a drawing of a WIP part.  Therefore if it is the WIP then it will revision that part/assembly as necessary.  On the contrary, if you update the version of the part/assembly in the drawing to a released version then when you go to release that drawing it will display the revision of the part/asm that is being referenced.

I'm talking about the specific Revision Referenced not just the Component, like in this simplified Scenario:


I've Designed an some parts, assembled them and generated a Drawing, now I'm ready to release everything. I'm done working with them. I generate my Release Candidate and everything looks ready, they will be 001 (Initial Rev)




The Release is approved and 001 shows in my History.



But what happens if I load Rev 001?


The Release intent was obviously to Release 001 of everything, which it did, BUT, the Assembly Released at 001 is referencing parts that where NEVER RELEASED (V1). This is a Problem! I understant the workaround (whinch requires 3 additional steps) but for Mid to Large Assemblies it would be a Pain

michael_bromley

@adrian_velazquez can you go into that version "My Rev 001 Release" and open up the BOM table, add the "state" column and see what it says there?  I do believe that they are actually released just do not show the triangle symbol.  This is a complaint that I've filed with Onshape as the communication is not consistent on how the release state is displayed.

adrian_vlzkz

@michael_bromley Like I mentioned the Parts themselves did get Released, the Read-Only Assembly does not reference the Locked Revisions, it references the In-Progress Workspace Parts. 

michael_bromley

@adrian_velazquez that is interesting.  I just ran the exact same test and when I go back to my release version it does show that the parts are released in the BOM.  The triangles are not shown in the assembly instance tree (which I agree is confusing), but apparently that is working as intended.  If you go to the part studio it will show the triangles that those parts are released.

adrian_vlzkz

That is interesting, My does not show the Parts in the Studio marked as Triangled. I did notice that the History shows a Triangle on my V1 whichs was only a version I created before the Release (I've only created One Release). Seems like you didn't have a Version before the your Release, not sure if id that, or a bug with us using a Custom Rev Counter, which is just a manual list

michael_bromley

This is probably worth bringing up with Onshape support as it seems something in your release process is not working correctly.  Can you view the release package for v1 and my Rev 001? Are they the same package?

Sorry to sidetrack your discussion Alexei!

adrian_vlzkz

There is no release Package for V1, I've only created 1 Release

APD

michael_bromley said:

This is probably worth bringing up with Onshape support as it seems something in your release process is not working correctly.  Can you view the release package for v1 and my Rev 001? Are they the same package?

Sorry to sidetrack your discussion Alexei!

@m@michael_bromley  No Problem.  For what it's worth, I'm not seeing triangled parts in Part Studios within my released workspaces either...

APD

@michael_bromley you are right about my proposed method being cumbersome! I was thinking through a typical sequential release workflow and my head began to hurt. So then I sketched it out in a google sheet (screen grab below) and now my head REALLY hurts!

The below is based on a simple 3 part PartStudio, a single sub-assembly(assy 1), a main assembly (assy 2) with drawings for all.

Google sheet link here for anyone interested...

https://docs.google.com/spreadsheets/d/1R2J0zqQOsjj93d3L1QLufzX9ybZP49jL2drl0m_Nszk/edit?usp=sharing

The "Workspace" region on the left refers to what you would see in the Main workspace.

Even for this very basic project, it becomes very complicated to keep track of.

I think I will try and stick to just releasing everything from the one candidate where possible!!




As always, any comments welcome.

adrian_vlzkz

@Alexei_Pittowicz This really captures why I'm concerned about how RM has been implemented. Hopefully some picks up on our feedback and improves the process. My concern on that is that the few discussions I've had with the Onshape teams is that this is intended behavior...  but why?  Too much flexibility does not make a good Data Management system.

APD

@adrian_velazquez I share your concerns and yes it would be good to have some best practice guidlines on OS Release Management seeing as it was developed for this from the ground up. However I've every confidence in the Onshape team. A flexible system I think is a generally a good thing as long as rigid and robust DM workflows can be implemented within. I'm still trying to find one that works for me*.

*Step2/Step7 of the above is a "fail" with sheet metal parts (which I use a lot) as when I release them from the part studio, it doesn't seem to take the flat patterns with them. So the flat pattern views in drawings don't update (it could be just my ineptitude; I have a ticket out for it)

APD

Every time we version the doc (and/or release something) a snapshot of the entire workspace is taken (regardless of which specific elements are released).

To keep data management simple, we could simply refer to the workspace version, with everything referencing MAIN.

Workspaces  V1,               V2,                ...V10. 
Parts:            Pt1_v1,        Part1_v2,      ...Part1_v10.
Assemblies:  As1_v1,       As1_v2.        ...As_v10
Drawings:     drg-Pt1_v1,  drg-Pt1_v2    ...drg-Pt1_v10

But this doesn't work (not very well anyway) as changes occur for different elements in different versions.  In versions 1 to 10, part 1 could be identical. 10 drawings showing the same part! Your suppliers are confused.  Your factory is confused.

This is why we have revisions. We only want to flag when a change has been made. 

I keep thinking of a video analogy. 
Each video frame is a version of the workspace. 
Each document Element (parts, assemblies, drawings) are like the pixels in the video frame.
The properties of each pixel (colour and brightness) change the way that Elements of a doc change through each version. (geometry or properties)

In a video, some pixels will not significantly change for long periods of time.They'll remain the same colour through many frames.
Don't some video codecs take advantage of this fact to allow higher compression levels? looking at the pixels and only recording the changes?

Could Onshape do the same? Intelligently decide if an element (part, assembly, drawing) has changed? And revision bump (or not) accordingly. Can we get the AI's working on this please?

I'm just rambling now so I'll stop.

adrian_vlzkz

Not rambling at all @Alexei_Pittowicz,  I saw this coming since the beginning with the idea of a Document being the container for multiple Items (Elements). I never liked that idea, and still don't; with Release Management you alleviate part of the problem by releasing Items individually, but still generates a Version at the Document level. This could be 1 part or 100s of elements (+any Branches); it gets overwhelming pretty quick.

This would be equivalent (in Windows or PDM) to having to create a version of and entire Folder in order to release a part+drawing in that folder. And for Onshape this might not be a problem in terms of Storage, but for a user the interaction is the same.

TimRice

adrian_velazquez said:

...I saw this coming since the beginning with the idea of a Document being the container for multiple Items (Elements)...

How would you imagine a different organizational approach to this? To give a normal file based analogue, would you prefer each element to be treated as a "file"? In this way we would only graphically show one element ("file") on the screen at once with some way to easily switch between elements. Or would you prefer to keep our current paradigm and simply allow element level versioning instead of document wide?

adrian_vlzkz

TimRice said:

adrian_velazquez said:

...I saw this coming since the beginning with the idea of a Document being the container for multiple Items (Elements)...

How would you imagine a different organizational approach to this? To give a normal file based analogue, would you prefer each element to be treated as a "file"? In this way we would only graphically show one element ("file") on the screen at once with some way to easily switch between elements. Or would you prefer to keep our current paradigm and simply allow element level versioning instead of document wide?

This would work, IMHO it's all about generating Data with intent. If I'm not modifying an element it should not generate new entries (at least not visible to the user).

robert_morris

TimRice said: Or would you prefer to keep our current paradigm and simply allow element level versioning instead of document wide?

Yes Please!

Alexei_Pittowicz said:

Could Onshape do the same? Intelligently decide if an element (part, assembly, drawing) has changed? And revision bump (or not) accordingly. Can we get the AI's working on this please?

This is the problem that I have with the current Release Management process. If you bump the revision of an assembly, it bumps the revision of all the parts in that document even if they don't have any changes. To understand why that is a problem, here is an example:

Example Situation
The BOM on all of our assembly drawing lists the revision of each part, so that everybody is on the same page as to exactly which part is supposed to be used. Now lets say I have an assembly with 10 unique parts that exist in the same document as the assembly, and I need to make a change to 1 part.

Scenario 1 (Current Onshape Release Management)
I make the change to the part and bump the revision of the part and drawing.
The assembly is also revision bumped since it needs to show that it's using the newly updated part. When the assembly is revision bumped it also automatically bumps all of the other parts as well. Because that happens, all 10 of the part drawings would need to be handed over to manufacturing and production since if the assembly calls out 'Rev B' for a part, they need to have a drawing for 'Rev B'. This would likely then be followed up by them questioning me as to what has changed on the parts because they cant find anything different.

Scenario 2 (Improved Situation)
I make the change to the part and bump the revision of the part and drawing.
The assembly is also revision bumped since it needs to show that it's using the newly updated part. No other parts are revision bumped because no changes to them were made. Manufacturing gets handed 2 drawings (1 part and 1 assembly) showing the changes. Job done.

Currently the only way to approach Scenario 2 is to either use the steps @Alexei_Pittowicz outlined in the original post, or move all of the parts into their own documents. Either approach (along with Scenario 1) is a lot of extra steps.

APD

@TimRice Files?!! God No!! I never want to hear the F word again!! Yes keep the current paradigm! It's a great one! And yes, keep the document level versioning which I think is a good thing too.

I would like to see improvements in the release candidate functionality (which I'm sure the onshape team is working on anyway!)

If I have released a drawing with an embarrassing typo... 
...I want to correct it VERY quickly and "up-revision" (or "bump") the drawing WITHOUT bumping the referenced assembly and parts.  I know this is possible now, but I would need to update each drawing view to reference a version.

I may still be at an early design stage and therefore would like the drawing to keep showing the main workspace so that any changes to parts can be more immediately shown in the drawing.

It would be good if I could leave the drawing views showing"MAIN" but on release, have the "super-AI-magic-candidate-dialog" go look to "see" if an element has changed since the last revision. (ie compare the element in the main workspace with the latest revision)  and if there is no difference, it doesn't revision bump. Or at least asks me sarcastically: "are you sure REALLY want to up-revision this part when it's exactly the same as the last time? Hmmm??"

I do appreciate that further into a project, the changes become less frequent and it's good practice to update assemblies and drawing views to reference revisions and versions.  Not least because of the speed increase across the system.

brucebartlett

There definitely needs to be some improvements in these areas, I am not a big fan of the multiple step release process to maintain control, I'd prefer to be able to release a drawing and all related items in one go but this becomes very hard to manage. I also find that the latest released items get lost in the versions, I imagine that I should be able to go somewhere in Onshape and be able to quickly navigate through the latest releases but unfortunately, the only way I can see to do this is via URLs to an external product structure chart. 

APD

robert_morris said:
"...This would likely then be followed up by them questioning me as to what has changed on the parts because they cant find anything different..."

This is the nightmare scenario that we're all trying to avoid. If I had to point to the single most important function of Release Management, it would be that it prevents exactly this situation.

michael_bromley

My vision is to keep document and version control just how it is today.  I like that it provides snapshots in time and can be used however the company see's fit, but I wish it was completely disconnected from release management.  As mentioned I would like to have a place that I can view the document at a high level and see the state of the parts, assemblies, and drawings as they relate to their released state.

Flow through/carry over of the released state would need to be introduced which would essentially replace the multi stepped approach that Alexei proposed.  For example, if I release a drawing and the corresponding part that part is now in the "release" state in the main version of the document and the drawing references the released part.  If a user attempts to make a change to it a warning pops up notifying them that it is released and if they accept then the drawing changes to the latest version and the part is no longer indicated as released.

I understand that these "snapshots" of the document need to be taken to capture the released state, but currently they muddy up the document version tree and make it hard to navigate.  I wish that the "snapshot" could be taken behind the scenes and not specifically displayed on the version control tree.  Again this would need some additional environment to view/navigate the releases. 

adrian_vlzkz

@michael_bromley that is a pretty good summary/conclusion of the current state of affairs, and I share the same thoughts.

If I come-of as negative or like I'm ranting, is because it seems (from my perspective) that Release Management is being too tailored to satisfy the end-user(designer). In my experience End-Users typically don't have business process needs (workflow) in mind, they will always request freedom of operation, which does not result in a well managed environment.

michael_bromley

Unfortunately I think the current workflow makes it confusing for both designers/end users as well as the parties interested in configuration management and control.  I've been working with release management since its earliest inception and I have yet to find a way that makes sense.  It is always difficult for me to understand the current state of parts/assemblies in a document at a quick glance without a lot of digging. 

robert_morris

michael_bromley said:

My vision is to keep document and version control just how it is today.  I like that it provides snapshots in time and can be used however the company see's fit, but I wish it was completely disconnected from release management.  As mentioned I would like to have a place that I can view the document at a high level and see the state of the parts, assemblies, and drawings as they relate to their released state.

I agree. Keep Versions at the document level, and make Release Management something separate at the part/assembly/drawing level. I think that could solve some of the issues people are having. Right now, it feels like Release Management is just Versions with a little extra metadata and automation.

PeteYodis

Would it be accurate to summarize and say one of the struggles currently is an easy way to navigate and consume released information, particularly the latest released information - regardless of which document or which versions in which documents things reside in?

BulletEngineering

PeteYodis said:

Would it be accurate to summarize and say one of the struggles currently is an easy way to navigate and consume released information, particularly the latest released information - regardless of which document or which versions in which documents things reside in?

That is exactly the issue. I have found that using versions with manual revision control is more easily browsed than the built in revision management. We ensure that only one version per document contains ANY and ALL released parts and drawings. Users merely navigate to the appropriately named "Production" version in the document they are viewing.

Our work around is still not sufficient, as documents default to a workspace view rather than a version and users must navigate through the version manager to find the Production version - often they forget and end up printing out an in-process drawing.

PeteYodis

@BulletEngineering Provided you could have a view of your data that was document agnostic and surfaced the things you care about, what kind of activities would you want to do with them?