Support #3642

Some thoughts about the project management

Added by Vadim 23 days ago. Updated 13 days ago.

Status:FeedbackStart date:09/28/2020
Priority:NormalDue date:
Assignee:Vadim% Done:

0%

Category:-
Target version:RapidDeploy - 5.0-FIX
Affects Version:5.0-FIX Additional version details:
Timesheet Code:

Description

Hello Rafael.

This message is definitely for You. :)

You should remember our earlier discussions regarding same structured project management and very recent project orchestration structure inheritance question. I used Your proposed approach to copy orchestration scheme and it definitely works. :) But at the same time I faced problems when projects differ in some small details like additional steps (I lost those from several projects after the orchestration scheme update). That's why I came back to these base questions: how to implement project inheritance so that changes in base project could be applied to a child projects, how to manage small differences in a same structure projects, how to manage most of our projects with a single RD project. :)

So I tried to think about all these things from another side. The main thing why we don't use single project for all deployments is inability of using a rollback functional - previous successfully deployed package can be from another project. I also am not sure if RD could manage several same project deployments in parallel when packages are different (I mean starting deployment with a LATEST package when package was already changed with another task).
So I was thinking about this and found that everything could be great if plan's project job settings had an additional settings parameter - package name filter. This parameter should solve all problems including a rollback actions as packages could be taken from a single project stack (all our packages we name by projects in format "project_name-version"). The default value for such parameter could be empty or it could be disabled by default and then system should act just like now - taking all packages from the project. But when enabled or with a value set in - taking just a certain set of packages.
In this case we could use single deployment project for most of our services. And this could make project managing totally different and very easy.

Please let me know what do You think about this. :) This is very important for us. Now we have 10 projects that are 99% identical, but should be managed separately. And this count will only grow up. Later that will be a great problem to go through all of those projects and update some small thing or error in orchestration scheme. I think that's not the best approach in a nowadays world. :) Hope that You will evaluate my suggestion. :)

Will be waiting for Your reply.

Best regards,
Vadim.

History

#1 Updated by MidVision 22 days ago

  • Assignee set to Rafael
  • Target version set to 5.0-FIX

#2 Updated by Rafael 13 days ago

  • Status changed from New to Feedback
  • Assignee changed from Rafael to Vadim

Hi Vadim,

Sorry for this late response, but I took some time off and we are also experiencing heavy workloads lately, so I couldn't take care of this before. :-)

As always, taking our tool to the limit... Thanks! This is definitely a great feedback for us! :-)

Let me give you some answers between the lines:

You should remember our earlier discussions regarding same structured project management and very recent project orchestration structure inheritance question. I used Your proposed approach to copy orchestration scheme and it definitely works. :) But at the same time I faced problems when projects differ in some small details like additional steps (I lost those from several projects after the orchestration scheme update). That's why I came back to these base questions: how to implement project inheritance so that changes in base project could be applied to a child projects, how to manage small differences in a same structure projects, how to manage most of our projects with a single RD project. :)

I've been thinking about this, and I remember one of our clients was actually using symbolic links (https://en.wikipedia.org/wiki/Symbolic_link) for something I think is exactly what you need.

In his case, he would have one "base project" to manage the orchestration file ("midvision-deploy-orchestration.xml") through the web console, and the rest of the projects would have a symbolic link to this "base project" orchestration file.

This is something you need to do manually, and whatever you change in any of the projects linked to the "base project" will be propagated to the rest of them, so you have to be careful with this.

So I tried to think about all these things from another side. The main thing why we don't use single project for all deployments is inability of using a rollback functional - previous successfully deployed package can be from another project. I also am not sure if RD could manage several same project deployments in parallel when packages are different (I mean starting deployment with a LATEST package when package was already changed with another task).

Here you have two things, one is managing pipeline failures and rollback, which you can actually manage by selecting the actual package version you want to use for failure or rollback, you don't necessarily need to use the "ROLLBACK" version.

And you don't need to save the job plan before you run it, so you can have a generic job plan, select whatever versions you want for projects, failure projects and rollback projects, and then hit "Run", and then go back to the job plan again, select different versions, and hit "Run" again, so the executions will be different.

On the other hand, you ask about using packages created during the job plan, and this is actually a bit tricky. The thing is if you select "LATEST VERSION", they will be resolved at the beginning of the job plan execution, so they will be replaced by whatever the version is and that's it. If you create a new package during the job plan using a task, for example, it doesn't matter, because the version was already resolved.

But if you select "NEW VERSION", a new package will be created right before running the project, and this can be useful if you want to include stuff into the project during the job plan, but you can end up with a lot of packages, which may be counter-productive.

So I was thinking about this and found that everything could be great if plan's project job settings had an additional settings parameter - package name filter. This parameter should solve all problems including a rollback actions as packages could be taken from a single project stack (all our packages we name by projects in format "project_name-version"). The default value for such parameter could be empty or it could be disabled by default and then system should act just like now - taking all packages from the project. But when enabled or with a value set in - taking just a certain set of packages.
In this case we could use single deployment project for most of our services. And this could make project managing totally different and very easy.

It is definitely a good idea, but not a concept we'd like to add now as it's quite specific and can be easily satisfied with other simple workarounds. :-)

Please let me know what do You think about this. :) This is very important for us. Now we have 10 projects that are 99% identical, but should be managed separately. And this count will only grow up. Later that will be a great problem to go through all of those projects and update some small thing or error in orchestration scheme. I think that's not the best approach in a nowadays world. :) Hope that You will evaluate my suggestion. :)

After having evaluated all your comments and needs, I'd say the best approach you could take is to use symbolic links, I have seen it working quite well in other clients and I think it could solve the main issue you're experiencing.

Remember you can have more than one "base project" and also be aware you can do this with other files, like the data dictionary one ("data-dictionary.xml"). :-)

I hope everything was more or less clear, let me know if you want any clarification or even to have a chat about this! :-)

Cheers!

Rafa

Also available in: Atom PDF