Always WIP

adrian_vlzkz

I'm trying to get a grasp on the some of the mindset behind Release Management and I have more questions than answers. The one thing that is bugging me the most right now is the concept that your Designs are Always Work-In-Progress (WIP). 

When submitting a Release Candidate for a Component, it automatically stamps a Version for that Workspace (Not the Document!), and the "Main" Workspace remains available for Modification as the Component moves thru the workflow up to Release.

This means I can open any Document, with all it's parts being "Released", and just start modifying and creating new versions without notifying anyone or requesting a "New Revision" to gain write access...

Am I the only one that finds this as very counter-intuitive and prone to issues?

TimRice

Adrian, every company is going to have a different workflow for creating parts. We would love to hear your specific workflow and see if we can create/attach any improvement requests and also to build more use cases. Perhaps a picture or detailed step by step release process would help us get a better idea of you workflow.

brucebartlett

No, I find this hard to manage too, I release a part then make modifications to a part studio and I am not sure if the originally released part has changed and now have the released part which is seen in the workspace and the released version which becomes hard to manage variations, if any, especially when coming back to a job after a few months. One way to solve this for assemblies is to link to the released version but that requires an extra step which I have not done on many of my designs at this stage however this would make sense. I also try to branch and do changes on a branch so as to keep the main node as per the release but this takes discipline to manage the main node and the branch and not do edits on the main, then manage merges but unfortunately you still can not grantee that the main is perfectly the same as last release which bugs me a bit . I am still very slowly learning on this and have not yet got a locked down workflow and I am also looking forward to more improvements in this area. 

chris_winters404

Hello fellow shapers,
It is a little difficult to follow the release cycle. I will state that when you create a release candidate the Onshape automatically creates a version of that release(now say vision,version, revision 10X real fast). You can follow in your document history. Please refer below

 


Now in regards to updating what happens after approval it would enter into a revision release cycle that depend on if you use the traditional workflow where you manually obsolete the old revision, or if you use Onshape's workflow where the old revision is auto obsoleted 


Now for what happens after engineering has released the first approved widget, assembly, or drawings subsequent revisions of that release as far as the rest of the company operations go for approvals and costings, I recommend using ERPlinc  for the communication outside of Onshape. It allows the whole company to be on the same page as far as what the current release is the allows workflow to keep the projects throughput on task with all of operations.
http://www.clearprocesssolutions.com/erplinc-app-for-onshape
They are in app store under the Data Management tab.
As far as working in the current model after release pending, that is a companies internal prerogative, If they use Enterprise I'm sure they can change permissions when the notifications for release review go out for view only to team members not involved in the approval. If not using Enterprise company practices would come into play(i.e. create a branch after release pending if engineer wants to work on current model)
I hope this helps. As always feedback is appreciated.
Stay awesome and keep smashing those towers.
Cheers,
Chris

P.S. I am an employee of Clear Process Solutions, the company who created ERPlinc.  This is to keep me honest but also allows me to speak to the functionality of this and the other services we provide.

adrian_vlzkz

Hi @chris_winters404, I understand how Release Management works my question or concern is Why? 

I'm having a really hard time trying to make sense of the vision or mindset behind the implementation of Release Management. IMHO there seems to be a few too many extra layers to the system. As an Admin/Analyst of the tool I need to understand these in order to design a system and guidelines. Managing Changes across many teams is more than just a few states in a Workflow.

billy2

I've been following this thread and rolling things back to the fundamental issues, hopefully I have something wrong. This is the simplest release work flow I can think of.

A part studio:


An assembly of part studio:


Release blue block from part studio:


How do I know blue part is released?:


Release assembly, blue shouldn't bump up, there's no changes to it:




Problems:
-when blue block was released I can't see that.
-when releasing the assembly, blue block is bumping up when it had no changes



Can someone please explain this very simple workflow. My fear is that I'll have to remember which parts have changed.

tim_hess427

@billy2 - One thing that I think is hidden in the assembly release workflow  - If your assembly is linked to released versions of your parts, they will not be bumped when you release the assembly. 

I struggled with the same thing early on! So, if you were to change the blue block reference to only show Rev A in the assembly, then it won't be bumped if you release the parts from the assembly. 

michael_bromley

I'm with @tim_hess427 and have found the best strategy at this point is to release at the assembly level.  Then unfortunately after the release you must go back to the assembly and update the version of all your parts to their released versions.  (This now treats them as parts from a linked document which is a bit annoying).  If a change needs to be made to a part you can make the change, update the version of that one part in the assembly, and again submit the assembly for release.  This will keep all your other parts at their current revision.

Many of us probably come from a conventional vault system where a release remains released until you say otherwise.  This is not the case in Onshapes environment and it may be partially due to how the Part Studios allow you to create many many parts versus conventional cad where each part has its own file. 

I have heard they are working on better tools and features to notify the user of a release, where used, and tracking of changes, but I haven't yet seen these features.

tim_hess427

I've also taken to making a couple of different assemblies - one is kept up-to-date with the latest released version of each part. The other just has the WIP parts from the current workspace. This way I can see how part updates affect the assembly quickly, while also have a fast reference to the current released configuration.

My assemblies have less than a couple dozen parts, so this insn't hard to maintain, but I imagine it doesn't scale well to some of the large assemblies I've seen people working with on here.

adrian_vlzkz

Hi @michael_bromley, in the case of a large design team, where multiple groups or users are working on parts/sub-assemblies these approach sounds like a nightmare.

This is why I'm expressing my concerns, the approach seems to be oriented to one-man or very small environments. I have an open mind and am excited, about adopting new practices, but so far I don't see the impact-to-benefit working for distributed design.

michael_bromley

@adrian_velazquez I don't disagree and I'm certainly following along to determine what some best practices are.  I'm hoping Onshape will yet again come up with some novel approach to this issue.

However if I think back to my conventional CAD days only one user could be working on the assembly at a time.  They would "check it out" make changes and "check in".  Onshape allows this check out and check in process to essentially occur in-situ.  If a designer makes a change to a part they then can update that single part in the assembly all the while other designers are working on the assembly.  Essentially your assembly is your master file and your part studios remain in work.  Where this breaks down is when one feature such as a sketch drives multiple parts.  The designer should catch this when they go to the assembly, but may not.

adrian_vlzkz

However if I think back to my conventional CAD days only one user could be working on the assembly at a time.  They would "check it out" make changes and "check in".  Onshape allows this check out and check in process to essentially occur in-situ.  If a designer makes a change to a part they then can update that single part in the assembly all the while other designers are working on the assembly.  Essentially your assembly is your master file and your part studios remain in work.  Where this breaks down is when one feature such as a sketch drives multiple parts.  The designer should catch this when they go to the assembly, but may not.

 Don't get me wrong, I LOVE the idea of working on Part/Assembly while a Release is being processed... BUT why is the Write Access the default? It would work best for collaboration if the "Active" workspace was create by Request instead of Automatically when you Version or submit a Candidate.

tim_hess427

@adrian_velazquez - That's an interesting idea. I supposed you could hack user permissions to revoke/grant user access to the documents, but that seems like it could be a hassle. At some point, it would be interesting to see change-requests build into Onshape. I could see an approved change request automatically unlock a document for the appointed user so that they can do their work. Once their work is complete and submitted for review, the workspace locks again. I guess this could all be done manually right now, though. 

michael_bromley

@adrian_velazquez thats an interesting thought.  However, if one person requested it to be active again then technically the whole document is active and all parts are free reign for everyone with access.

adrian_vlzkz

@michael_bromley I know, that's why the whole idea of Document Level version system concerns me. I've also heard Tab or Part level versioning might me a thing in the future, so that is why I'm here expressing my experience/opinions. 

 I think it's still early enough for Onshape were we (us Release Management users/CUSTOMERS), could help shape the product, since it seems I'm not the only one struggling with some of these concepts. Having an environment where everything is always  editable, is not what I would call "Managed"

TimRice

adrian_velazquez said:

...I think it's still early enough for Onshape were we (us Release Management users/CUSTOMERS), could help shape the product...

YES! This has been a very insightful discussion so please keep it going!

michael_bromley

@adrian_velazquez here is another scenario:

1. You submit a release package that is approved for some parts and assemblies.  This is stored as a version as is the case right now.
2. A user then goes to make a change in the automatically created "main" version to a part or assembly that had been previously released. 
3. A window pops up warning the user that executing the change will modify a previously released part/assembly and give them a list of the part numbers/revisions affected.
4. The user can then choose to proceed with the change or abort. 

I can imagine building on this in the admin settings if a company wants enhanced control.  That "pop up" in step 3 could be a notification to a manager to allow or disallow the change.

An area for comments/reasoning of the change would also be great.  This could essentially help build out a revision table on the drawing.  The user could enter "Change due to ECR XXXX".  

owen_sparks

@michael_bromley That all sounds rather logical and well thought out

Owen S.

adrian_vlzkz

@michael_bromley Yes, something along those lines is what I would expect for a "Controlled" environment. Right now it just feels like a Free-for-all, in terms of modifying Data

APD

@michael_bromley I like that last scenario. Start editing a part and you get some kind of feedback as to the impact on other elements across the system. 
Also after a part is released, that particular recorded revisioned bagged-and-tagged snapshot is identical to what you see in the live part studio. So it would be nice if there was some kind of display to highlight that fact. Maybe a strategically-placed little black triangle. And then, when you begin editing the part, that little triangle evaporates dramatically like Tom Holland at the end of Infinity War. 

tim_hess427

I just wanted to drop in here because I referenced this thread in a discussion about release workflows: https://forum.onshape.com/discussion/11041/release-management-workflow-procedure#latest

Your discussion here sparked an idea that I think is interesting, and I'm curious as to your thoughts:

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.