UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21. Read more.
UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21.Read more.
Vice Admiral
Vice Admiral
248 views

Designer project check-in GitHub?

Jump to solution

NetIQ IDM 4.7.4 AE

 

Does anyone know support for designer project check-in for Git (or anyone used Github) ?

 

We know support for driver packages, but i am asking here for project check-in

 

We don't use packages for custom driver development, its slow developer experiences and very messy as this of now.  we do code revision using project check-in (subversion).

driver configuration files are much faster to work, light weight, easy xml blot(in an environment with high pace change culture), we find driver packges unnecessary "overlay on top of configuration files and development experience and extra overhead of package management)

 

 

Regards.

Maqsood.

 

 

0 Likes
1 Solution

Accepted Solutions
Knowledge Partner Knowledge Partner
Knowledge Partner

@maqsood wrote:

Does anyone know support for designer project check-in for Git (or anyone used Github) ?

No, this is not supported by Micro Focus yet.

We don't use packages for custom driver development, its slow developer experiences and very messy as this of now. 

driver configuration files are much faster to work, light weight, easy xml blot(in an environment with high pace change culture), we find driver packages unnecessary "overlay on top of configuration files and development experience and extra overhead of package management)

Well, I beg to differ, but I see it has a steep learning curve and requires some initial investment. Also the default packages are often no good examples and should be avoided, imho.

Once you have got the hang of it, packages are not only faster and more efficient but also modular, handle dependencies, support easy staging and patching etc. pp.

we do code revision using project check-in (subversion).

Versioning is a good first step, only with subversion you can only do it on a project level, not on individual drivers or even parts of a driver inside a Designer project.

If you move to git you'll get all the power of it, but also loose Designer's help with commits and updates. Designer does some consistency magic behind the scenes that is effectively not reproducible when you commit/push/pull with an external client against git. This means, you can only check in at project level without risking inconsistencies in the project, and this also prohibits the use of branches and merges, which are a major git benefit you'll be unable to make practical use of.

That said, we do use git here for Designer projects and are in the process of migrating all subversion-based projects to it. While the usable set of git features with Designer projects is basically the same as with subversion, it's much faster, allows for multiple server sides (our own + customer), supports offline commits, easy and fast compares between commits (only slightly useful, but you learn to know the project structure in detail 🙂

As client, you can use the git plugin that comes with Designer now, but it's a nightmare in terms of usability, imho. If you can afford it, have a look at fork.dev, money well spent and a pleasure to work with.

Some hints to get started:

  • when you check out from git, rename the project folder case-EXACT to the name of the project it contains. Designer will not be able to work with it otherwise, even on case-INsensitive file systems.
  • Before you commit  anything, close the project and all open editors from it in Designer. I've seen incomplete commits just because a saved change has not been written to disk. If someone else checks out such a commit, the project may be in an inconsistent state for him.
  • Same goes for pulls: Designer does not detect or reload externally made changes from disk, so you might accidentally without noticing overwrite new code pulled in with an earlier version Designer still has in memory, otherwise.
  • commit often and in small portions, and use verbose commit messages. Much easier to isolate a change in history by comparing commits then.
  • Use tags to mark releases or milestones, as with subversion.
______________________________________________
https://www.is4it.de/identity-access-management

View solution in original post

3 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Alas, due to the way the file/memory model of Designer is laid out, they have issues supportig GIT.  There is SVN support and it is so-so.

They added GIT for packages as an attempt to help as much as they could without a major re-write.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

@maqsood wrote:

Does anyone know support for designer project check-in for Git (or anyone used Github) ?

No, this is not supported by Micro Focus yet.

We don't use packages for custom driver development, its slow developer experiences and very messy as this of now. 

driver configuration files are much faster to work, light weight, easy xml blot(in an environment with high pace change culture), we find driver packages unnecessary "overlay on top of configuration files and development experience and extra overhead of package management)

Well, I beg to differ, but I see it has a steep learning curve and requires some initial investment. Also the default packages are often no good examples and should be avoided, imho.

Once you have got the hang of it, packages are not only faster and more efficient but also modular, handle dependencies, support easy staging and patching etc. pp.

we do code revision using project check-in (subversion).

Versioning is a good first step, only with subversion you can only do it on a project level, not on individual drivers or even parts of a driver inside a Designer project.

If you move to git you'll get all the power of it, but also loose Designer's help with commits and updates. Designer does some consistency magic behind the scenes that is effectively not reproducible when you commit/push/pull with an external client against git. This means, you can only check in at project level without risking inconsistencies in the project, and this also prohibits the use of branches and merges, which are a major git benefit you'll be unable to make practical use of.

That said, we do use git here for Designer projects and are in the process of migrating all subversion-based projects to it. While the usable set of git features with Designer projects is basically the same as with subversion, it's much faster, allows for multiple server sides (our own + customer), supports offline commits, easy and fast compares between commits (only slightly useful, but you learn to know the project structure in detail 🙂

As client, you can use the git plugin that comes with Designer now, but it's a nightmare in terms of usability, imho. If you can afford it, have a look at fork.dev, money well spent and a pleasure to work with.

Some hints to get started:

  • when you check out from git, rename the project folder case-EXACT to the name of the project it contains. Designer will not be able to work with it otherwise, even on case-INsensitive file systems.
  • Before you commit  anything, close the project and all open editors from it in Designer. I've seen incomplete commits just because a saved change has not been written to disk. If someone else checks out such a commit, the project may be in an inconsistent state for him.
  • Same goes for pulls: Designer does not detect or reload externally made changes from disk, so you might accidentally without noticing overwrite new code pulled in with an earlier version Designer still has in memory, otherwise.
  • commit often and in small portions, and use verbose commit messages. Much easier to isolate a change in history by comparing commits then.
  • Use tags to mark releases or milestones, as with subversion.
______________________________________________
https://www.is4it.de/identity-access-management

View solution in original post

Vice Admiral
Vice Admiral

@lhaeger  Thank you for the info

 

Yes, we use base package just to get start  with our driver as a base template (RESTbase as example), export to config file and use that config file  to add our own custom policies (on to it) ( for us the process is extremely fast to add them up and do changes, so speed is a clue here,  we have 200+ drivers managed in different projects (repos) group as "business solution they solve"), we also see subversion does maintain changelog /revisions at project level, driver level, and even on any item level within the driver when we do changes and commit to subversion.

packages model could be good as a general development practice, but as the designers is  now itself "externally slow in many cases" and it does not even motivates to use package based development because of experience as you said you have to adopt and start. (git for packages, project check in for subversion), 

the use case we have to to leave on-prem subversion server and replace it to with cloud based solution, we are using GitHub enterprise already for other things, we are looking for if subversion repos can be migrated to github and we can use subversion from designer to GitHub. 

One thing i wonder, if someone within NetIQ community can demonstrate or go through CI/CD process for drive development process that would be nice for others to learn and adopt.

A simple case (do not make it complex driver, start simple)

1. Use of packages

2. Use of cloud code repos github with desinger.

3. Designer headless (for fully automated pipeline to dev, test and prod)

 

 

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.