Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Release Management - Workflow Procedure

2»

Comments

  • michael_bromleymichael_bromley Member Posts: 110 PRO
    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 certainly one of the issues.

    The other major issue under discussion here is how the releases flow through/propagate (or don't) in the document.  For example, an assembly of 5 parts is released by one designer.  Another then goes to make a change to one part and release the assembly with the one updated part.  The release would try to revision the other 4 parts and the designer does not know whether or not they truly changed without doing some investigating.  This could result in all 5 parts being released at a new revision when only one truly had a change.
  • michael_bromleymichael_bromley Member Posts: 110 PRO
    @Alexei_Pittowicz that level of intelligence would be awesome to have! I can envision implementing that for parts, but can only imagine how complex that may get for assemblies.  I have full faith in Onshape implementing an awesome solution though.

  • Cris_BowersCris_Bowers Member Posts: 281 PRO
    This discussion makes me happy that I'm not using release management and don't really have a need for it currently.
  • adrian_vlzkzadrian_vlzkz Member Posts: 266 PRO
    This discussion makes me happy that I'm not using release management and don't really have a need for it currently.
    We are not formally using it either, but my certainly testing the heck out of it. It will have heavy weight on our company deciding if Onshape is something we could migrate to from SW+PDM
    Adrian V. | Onshape Ambassador
    CAD Engineering Manager
  • christopher_quijanochristopher_quijano OS Professional Posts: 50 PRO
    One of the issues I have run into in our testing is that when we modify a part we typically don't go and create a new revision for all the assemblies that contain that part. For example if we have Assy01 with P1, P2, and P3 in it and everything is at RevA. Now if I change P1 and make it RevB and this can be a rolling change we will leave Assy01 at RevA. At this point I have not found a way to have Onshape open Assy01 with the latest released versions of P1, P2, and P3. Onshape basically forces you to create a new assembly revision every time a part is changed. If P1 is shared in ten different assemblies this starts to become a real time sink.
  • adrian_vlzkzadrian_vlzkz Member Posts: 266 PRO
    edited February 2019
    One of the issues I have run into in our testing is that when we modify a part we typically don't go and create a new revision for all the assemblies that contain that part. For example if we have Assy01 with P1, P2, and P3 in it and everything is at RevA. Now if I change P1 and make it RevB and this can be a rolling change we will leave Assy01 at RevA. At this point I have not found a way to have Onshape open Assy01 with the latest released versions of P1, P2, and P3. Onshape basically forces you to create a new assembly revision every time a part is changed. If P1 is shared in ten different assemblies this starts to become a real time sink.
    Yes, this just one of many scenarios. So when I read stuff like this from Onshape:



    Can't help but get a bit irritated...




    Adrian V. | Onshape Ambassador
    CAD Engineering Manager
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    I think this discussion is very closely related to the discussion over here: https://forum.onshape.com/discussion/10952/always-wip

    In that thread, @adrian_velazquez made a really good point about the default view of a document being the main workspace. In my previous experience with other systems, if you just look open a part or assembly, the system would serve you the most up-to-date revision by default. If you wanted to make changes, then you'd create a workspace and check-out your parts/assembli/drawings, make your changes and go through the approval/revision process if necessary before checking them back in.

    In Onshape, the scenario is reversed. The default view is the open workspace, where you don't have clear visibility to status or revision of parts, and you just mark specific model states as "released". It doesn't feel like there's a controlled environment that you can selectively push changes into. 

    So, here's a thought experiment - what if we could delete the "Main" workspace (but keep the branch) and all edits would need to be done within other branches before being released back into the main branch? I'm not sure how you would handle the release of a single part created in a multi-part part studio. Perhaps you treat it like a derived part behind the scenes so that you can show only the parts that are released. This doesn't really solve all of the release workflow issues, but at least this way there is a clear place to go in order to see all of the most recent released parts in the document. 
  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,140 PRO
    edited February 2019

    This is a great thread and is really highlighting the various issues with release management which I have struggled with. Release management definitely adds another layer of complexity on top of the version tree and to makes it more painful to understand where a document is at. I do enjoy just working on my documents without released parts and manually handling the release with versions but really want release management to take out human errorr. 


    So, here's a thought experiment - what if we could delete the "Main" workspace (but keep the branch) and all edits would need to be done within other branches before being released back into the main branch? I'm not sure how you would handle the release of a single part created in a multi-part part studio. Perhaps you treat it like a derived part behind the scenes so that you can show only the parts that are released. This doesn't really solve all of the release workflow issues, but at least this way there is a clear place to go in order to see all of the most recent released parts in the document. 
    Tim, I haven't thought through all the scenarios or had time to test but definitely, think this has merit and feels like what I want to see. I really want a clear, reliable uneditable version of the document that shows all the latest releases. I was thinking that the unedited main sorts of gives this if you never make any edits in it and only edit on the branches then merge and release but this is not true, as changes can come across from the branch so I never have confidence now that the main is the latest. I'd be really keen to see a solution to this. 
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    @brucebartlett - Exactly. I was thinking about setting this scenario up and testing it myself, but one thing that would be required is to remove the ability and need to merge things into the main branch. Rather than merging changes to the main branch and then releasing the branch (which may now include un-released parts), a single release action would push released items to the main branch, and leave the other stuff in the workspace branch. 
  • owen_sparksowen_sparks Member, Developers Posts: 2,660 PRO
    Can we get closer to this with the existing branches?  A "release" is its own branch containing nothing but the released items in it.  At least that way we have some sort of visual map.
    Then If sharing could be limited to individual branches then unwanted exposure to WIP could be handled.  All the bells and whistles would be nice but small chunks might be more achievable.

    Owen S
    Business Systems and Configuration Controller
    HWM-Water Ltd
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    @owen_sparks - How would you ensure that the "released" branch only has released parts/assemblies/drawings? If I merge my development branch into "released", wouldn't the current state of everything merge, released or not? I may be missing something though. 
  • owen_sparksowen_sparks Member, Developers Posts: 2,660 PRO
    Sorry my comment wasn't well written.  I'm proposing that a release operation automatically create a read only branch containing the released items.  Then that branch only is shared with the end user.

    The designer can see an overview of the whole document through the existing branch manager and end user can't accidentally use a live main workspace.

    Regards,
    Owen S.
    Business Systems and Configuration Controller
    HWM-Water Ltd
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    Oh! Yes - that sounds awesome. 

    That would also probably make it easier to share things with outside users (suppliers, manufacturing, etc.) without having to create "cleaned" documents to hide in-progress or unrelated data. 
  • adrian_vlzkzadrian_vlzkz Member Posts: 266 PRO
    What I would like to see is an option on the Company settings where you can specify the Default Open for your company, ie:

    Default Workspace when Opening a Document:
    • Main Workspace
    • Latest Version (Read Only)
    • Latest Revision (Read Only)
    In the future this setting could be implemented at the Project Level or even the Team Level.

    Another great Option would be to Hide Main Workspace when sharing View Only.


    Adrian V. | Onshape Ambassador
    CAD Engineering Manager
  • raj_Onshaperaj_Onshape Onshape Employees Posts: 110
    Sorry my comment wasn't well written.  I'm proposing that a release operation automatically create a read only branch containing the released items.  Then that branch only is shared with the end user.

    The designer can see an overview of the whole document through the existing branch manager and end user can't accidentally use a live main workspace.

    Regards,
    Owen S.
    Right now the only way to view the released items anywhere is to go insert dialog pick the document you are interested in and hit the black triangle. Now in the dialog all you will see is the latest revision of each thing that was released from the document regardless of which version it was.

    Also a release only branch is tricky. Imaging you have a part studio with three parts and each part was released in a different version. Now it would be very tricky to have a view for the part studio that pulls these potentially different parts from different versions into the same workspace.
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    @raj_Onshape - I imagine any part studios in the release branch to function like a read-only part studio where all of the parts are "derived" from the latest release for each part.

    Right now I can open a part studio and manually derive all of my released parts into the studio and ignore my other parts. Couldn't something similar be automated and then displayed as a read-only branch?
  • romeograhamromeograham Member, csevp Posts: 675 PRO
    This is, indeed, an awesome discussion - I'm so glad you guys are putting energy into it, and that Onshape folks are participating too. I share many (all?) of the frustrations above.

    However, I'm trying my hardest to use RM in my production work - and I really, really appreciate the fact that it keeps track automatically of revision levels. My main complaint (as some have already eloquently described) is that the Version and History Manager is cluttered with every single released item...I like the discussions centering around reducing that clutter for sure.

    Keep it coming, and here's hoping OS has some improvements up their sleeves.

    But, hey: happy Third Friday everyone! Maybe there will be something tonight!
  • PrachiPrachi Member, OS Professional Posts: 262 ✭✭✭
    I would like to see more granular versioning of parts specifically.
    Currently when a version is created or any change to one part within a studio all drawings show as out of date. Using part configurations now and like it a lot, however, all assemblies show as out of date even when a new part configuration is added. Versions must be used to see a new part added to a configuration. A month or 6 months down the line I don't necessarily remember what the change was and am obliged to go through all assemblies and find out if it matters and do I need to update.
    Would like versioning to be allowed for individual parts.
    Drawings and assemblies could then show out of date for pertinent changes only.
    When inserting part configurations no need to see all as out of date just because a new config is added.

    For the time being I'm currently working on my own and that will change and not using release management as I've been able to keep track and manually raise revisions but as others come on board it will be wanted and a more granular method would be good there as well. 
  • BulletEngineeringBulletEngineering Member Posts: 24 PRO
    PeteYodis said:
    @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?  

    Machine shop personnel want to quickly find drawings for parts and often also drawings for related parts (used on a common assembly). They do not often have the part number memorized, but do know the name and part number for the product (the top level assembly). They occasionally also require solid models, but always with an accompanying drawing. Warehouse and purchasing personnel similarly wish to access drawings of released parts and assemblies for quality control and for part identification/differentiation. They do know individual part numbers, but the search interface is slow when they have to manually filter each query so they usually resort to browsing. 

    In all cases, the context is usually groups of parts associated with an assembly, so they would prefer to browse exclusively by released assembly rather than by document. Links to all released drawings referencing said released assemblies would be listed in the assembly record. Navigating to an assembly would open a BOM view with records for each part containing links to the part studio and to all released drawings referencing each part. To save on clicks, if the links to the documents had a context menu with the option to export or print it would be ideal. 

    Further, the shop personnel prefer speed to detail when browsing, so a basic thumbnail and text BOM view with no document window (to eliminate loading lag) would be preferred. If the thumbnail view reduces performance, it would be better to have  a text only list.

    A wireframe of what I imagine - top level:


    Drilling down into an assembly:







  • BulletEngineeringBulletEngineering Member Posts: 24 PRO


    So, here's a thought experiment - what if we could delete the "Main" workspace (but keep the branch) and all edits would need to be done within other branches before being released back into the main branch? I'm not sure how you would handle the release of a single part created in a multi-part part studio. Perhaps you treat it like a derived part behind the scenes so that you can show only the parts that are released. This doesn't really solve all of the release workflow issues, but at least this way there is a clear place to go in order to see all of the most recent released parts in the document. 

    This is similar to the GitFlow version management approach that Onshape recommended before they added Release Management. I think that it provides a preferable structure to the current Release Management implementation for many use cases (my company included). 

     https://learn.onshape.com/learn/article/gitflow-version-management

    As others have noted, the approach could be greatly improved if OnShape added a release workflow for merges and adding a lock to the 'main' branch, only allowing edits during the release process.

  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,140 PRO
    As others have noted, the approach could be greatly improved if OnShape added a release workflow for merges and adding a lock to the 'main' branch, only allowing edits during the release process.

    I like the sound of lock to main branch,  only allowing edits during the release process.  Can you expand what you mean by this? 
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • BulletEngineeringBulletEngineering Member Posts: 24 PRO
    I like the sound of lock to main branch,  only allowing edits during the release process.  Can you expand what you mean by this? 
    What I envision is an additional release management option: managed GitFlow releases,

    A locked branch (nominally MAIN or the primary trunk) would have the workspace hidden by default and contain only versions, perhaps named something useful like "RELEASE 1.00 - 1 JAN 2019".

    Default browsing and search result behavior for all users would be to open the latest version (release) from the MAIN trunk. This makes it easier for infrequent users to find production ready released documents and they would have to go out of their way to navigate to unreleased versions or to workspaces.

    Versions (releases) as always could be branched to create new workspaces for edits. When a change is ready for release, the user creates a version in the edited branch and flags it as a release candidate. After the requisite approvals (skipped if the approval option isn't checked in company preferences) the release candidate may be merged into MAIN. Because merging sometimes requires extra work (changing callouts on drawings, updating assemblies, etc) MAIN would temporarily contain a workspace named something like "WORKING CANDIDATE 1.01" and (if the preference is set) drawings would be watermarked "RELEASE CANDIDATE" until the changes were finalized (second approval process?) and MAIN would have a new version created, "RELEASE 1.01 - 15 JAN 2019", and the workspace would be removed. The state of all tabs in the latest release would be changed to RELEASED, and the state of all tabs in all other versions would be changed to OBSOLETE.


    In this process any changes to tabs would be tracked with a minor revision increment (ex. A.01 > A.02 > A.03) until the final release, when it would advance to the next major increment (A.03 > B ). The major revisions would conform to company standards, the minor revision trackers are merely to indicate that something had changed inside the release candidate and could be stored in a separate tab property. This avoids hundreds of unreleased revisions while still tracking incremental changes between releases. 


    Software guys have been working with versions and branching for a long time and have worked out most of the difficulties to the process in the context of sofware development. The hard part to adapt to a manufacturing/mechanical design context is change management beyond the CAD system - the guys on the shop floor get royally p*ssed after the 3rd or 4th revision with nothing new (released because another part from the same part studio was modified), but a software dev wouldn't really care if you made 100 new versions of a file with nothing changed but the timestamp, provided the code still compiles and passes their automated unit tests. This means that we have to be more deliberate with our releases than a software team would. 

    The above thoughts are just a brain-dump and definitely would be subject to modification under the harsh glare of reality and the needs of different contexts in other organizations.
Sign In or Register to comment.