Highlighted
Knowledge Partner
Knowledge Partner
1922 views

Designer + Git

We've batted this around before, but it doesn't seem like git support in Designer is going to happen any time soon. What would it actually take to do this without official support?

I've worked with several revision control systems. In the end, what they care about most is files. We have files, they're stored under the workspace directory.

Would it be sufficient to create a git repository, and shove the workspace in to it so that it can be managed using git's tools? Sure, it wouldn't be as pretty and nice as doing this in Designer itself, but would it work? If not, why not?

I think the basics of it might work.
Labels (1)
0 Likes
22 Replies
Highlighted
Knowledge Partner
Knowledge Partner

On 01/16/2019 11:53 AM, Lothar Haeger wrote:
> ab wrote:
>
>> I think what I want is something kind of like
>> workspaceDirectory/projectDirectory/Model/Project, and maybe (but maybe
>> not) the EdirOrphan directory too. I have not delved into this much, but
>> this is an initial rambling.
>>
>> Ideally I want the Outline view in Designer, and I want everything in that
>> outline view (every eDir object) to have an XML file structured/formatted
>> like we expect to find in a driver config export. If I change a driver
>> config object's trace settings, those go in the driver config object file.
>> If I modify a policy's rules, those go in the policy's files. If I link
>> in a new policy, that goes in the appropriate channel's (or maybe driver
>> object's for Input or Output Transformation Policyset changes) files.

>
> The file/folder structure under EdirOrphan is already quite that, IIRC.
>
> For example, in one project I find in Model/EdirOrphan a file called
> DAO2WEXA.DriverSet_ describing a driverset object in XML syntax. The folder
> Model/EdirOrphan/DAO2WEXA then contains files named LFODMXZA.Driver_ and
> LFODMXZA_8CYQAFJH_DirXML-ConfigValues.xml which describe a certain driver in
> XML (plus LFODMXZA_icon.gif). The folder Model/EdirOrphan/DAO2WEXA/LFODMXZA
> then contains objects named C8DNX0RQ.Subscriber_ and YGVG2OIO.Publisher_
> describing... well, you get the picture.


It's something, yes, though why there are GIF files in there I cannot
figure out (I know some of them are the driver icons, but those should be
attributes on objects, not separate files; just leave it in the XML like
the driver config export does). The names are an issue, but I would think
keeping the names like they are in the directory, rather than looking like
they may be GUID-related, may be feasible.

> If file names were more descriptive working with external git would be easier,
> but the real challenge is to keep the refereneces that are stored all over the
> place consistent for each revision that gets committed.
>
> Not a problem as long as you check in the whole project but a real challenge
> when several people work on the same project on different drivers. That is the
> key point where IDM differs a lot from traditional software projects: when I
> build e.g. Apache Studio from source, I always build the whole thing, not just
> one Plugin or feature of a plugin. And only if is compiles to the very end, I
> get a running product. And there's just one source code repository to build
> from. With IDM 3 developers may share the same project while another two work
> with their own. So three projects exist and it all comes together in the live
> system. It would be a lot easier if there was only one single Designer project
> for each IDM environment everyone involved would be required to work with. Only
> that designer could not handle such a project for any non-trivial environment
> because of it's size... 😞


I'm not sure I agree here, but admittedly I didn't write Designer.

Git repositories, by definition, are complete repositories. This differs
wildly with older things like SVN which allow you to "checkout" a portion
of the code, modify it, and check it back into the only real repository,
the one on a server somewhere else. Git instead only works if you have
the full repository, and then you modify some part of it and check that
in, and Git handles the merging when necessary.

Because everybody has everything, references are either there and
complete, or not there at all, or should be anyway. If I delete a policy
in Designer, that not only deletes the object (and queues a delete to
eDirectory the next time I deploy) but it also deletes any policysets
pointing to that object . When i then commit, both the references all
over, and the object itself, go away. When somebody else commits code,
either it dealt with that object or its references, or it did not. If
not, the merge is fine; if so, the you have a merge conflict, and manual
intervention happens, but at least it's done BEFORE the commit actually
goes to what we may label "upstream".

The result of this is I think, as with every project out there, using Git
helps a lot more because it deals with the whole repository, not just some
fragment which, in isolation, may be just fine, but when considered as a
critical part of everything, may be broken by something completely
unexpected. Designer needs to work in this way, not in the old way which
worked with SVN. Learning Git, with a mindset trained by SVN, was hard,
and it wasn't until I stopped thinking about SVN's way of doing things
that Git became intuitive, and i was able to use it well (or at least much
better; I'm no expert).

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

lhaeger;2493780 wrote:
ab wrote:

> I think what I want is something kind of like
> workspaceDirectory/projectDirectory/Model/Project, and maybe (but maybe
> not) the EdirOrphan directory too. I have not delved into this much, but
> this is an initial rambling.
>
> Ideally I want the Outline view in Designer, and I want everything in that
> outline view (every eDir object) to have an XML file structured/formatted
> like we expect to find in a driver config export. If I change a driver
> config object's trace settings, those go in the driver config object file.
> If I modify a policy's rules, those go in the policy's files. If I link
> in a new policy, that goes in the appropriate channel's (or maybe driver
> object's for Input or Output Transformation Policyset changes) files.


The file/folder structure under EdirOrphan is already quite that, IIRC.

For example, in one project I find in Model/EdirOrphan a file called
DAO2WEXA.DriverSet_ describing a driverset object in XML syntax. The folder
Model/EdirOrphan/DAO2WEXA then contains files named LFODMXZA.Driver_ and
LFODMXZA_8CYQAFJH_DirXML-ConfigValues.xml which describe a certain driver in
XML (plus LFODMXZA_icon.gif). The folder Model/EdirOrphan/DAO2WEXA/LFODMXZA
then contains objects named C8DNX0RQ.Subscriber_ and YGVG2OIO.Publisher_
describing... well, you get the picture.

If file names were more descriptive working with external git would be easier,
but the real challenge is to keep the refereneces that are stored all over the
place consistent for each revision that gets committed.

Not a problem as long as you check in the whole project but a real challenge
when several people work on the same project on different drivers. That is the
key point where IDM differs a lot from traditional software projects: when I
build e.g. Apache Studio from source, I always build the whole thing, not just
one Plugin or feature of a plugin. And only if is compiles to the very end, I
get a running product. And there's just one source code repository to build
from. With IDM 3 developers may share the same project while another two work
with their own. So three projects exist and it all comes together in the live
system. It would be a lot easier if there was only one single Designer project
for each IDM environment everyone involved would be required to work with. Only
that designer could not handle such a project for any non-trivial environment
because of it's size... 😞


--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)


This is a different but related problem. Having multiple people working on the same project is difficult, at best. It would be ideal to use git to manage the branch/merge problem with multiple developers, but I think that's beyond the current design of what's on disk and what we know about it.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

alekz;2493743 wrote:
On 2019-01-16 15:46, dgersic wrote:
>
> We've batted this around before, but it doesn't seem like git support in
> Designer is going to happen any time soon. What would it actually take
> to do this without official support?
>
> I've worked with several revision control systems. In the end, what they
> care about most is files. We have files, they're stored under the
> workspace directory.
>
> Would it be sufficient to create a git repository, and shove the
> workspace in to it so that it can be managed using git's tools? Sure, it
> wouldn't be as pretty and nice as doing this in Designer itself, but
> would it work? If not, why not?
>
> I think the basics of it might work.
>
>

Hello
We are using Bitbucket (which is using git) manually outside of Designer
and have done so for almost a year.

So far we haven't had any issues I'm aware of.



--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.


That's interesting, and encouraging. Any best practices to share? Have you explored using .gitignore to keep it from maintaining any of the other stuff that Designer caches that isn't helpful?
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

On 2019-01-16 17:56, dgersic wrote:
> That's interesting, and encouraging. Any best practices to share? Have
> you explored using .gitignore to keep it from maintaining any of the
> other stuff that Designer caches that isn't helpful?

We use it for a project where the packages are built.

Have to check if we are using .gitignore.

When you are done with developing you do a git add -A, then a git commit
-a -m "message" and finally a git push

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

I also work with git. I mainly do drivers and you can export them nicely. As far as I know the same doesn't apply to workflows or other UserApp entities.

The main benefit I see is being able to diff different commits and see what changed, when and who's to blame. I guess that the same could be achieved without git, just by using diff exported_driver_v1.xml exported_driver_v2.xml, but then you loose commit messages.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Hi!

I'm interested in how you work with drivers and export them.

I'm used to work with code like C or Java where everything is stored in a sensible file structure and having a hard time figuring out how to work effectively in the Designer.
I really miss the branch/merge and diff that gives me a lot more freedom to elaborate during development.

When you say you're working with drivers, do you implement each driver in a separate project?
And then export them and import them in a system project for deployment to IDM-server?

If so, it sounds somewhat like something I've been considering.

Can you even branch and merge using your working pattern? That would be really nice.
How do you perfrom (unit)testing on the individual drivers?
Or do you only test them after delivery (export/import)?

BR
/Thomas
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

liasson;2498420 wrote:
Hi!

I'm interested in how you work with drivers and export them.

I'm used to work with code like C or Java where everything is stored in a sensible file structure and having a hard time figuring out how to work effectively in the Designer.
I really miss the branch/merge and diff that gives me a lot more freedom to elaborate during development.

When you say you're working with drivers, do you implement each driver in a separate project?
And then export them and import them in a system project for deployment to IDM-server?

If so, it sounds somewhat like something I've been considering.

Can you even branch and merge using your working pattern? That would be really nice.
How do you perfrom (unit)testing on the individual drivers?
Or do you only test them after delivery (export/import)?

BR
/Thomas


Working with Designer + SVN, I treated the project as a single monolythic thing that could be checked out / checked in. I arranged my work to only change a related collection of things at a time, and described what changed in the checkin comments.

I don't especially like that, but it worked. I think we need to envision how Designer + git would work, in order to move this idea forward. How would you use it, if you had it? What functionality would you use? What would you ignore?
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Maybe I was a little vague.
I was mainly interested in msira's way of working.

BR
/Thomas
0 Likes
Highlighted
Absent Member.
Absent Member.

dgersic;2493737 wrote:
We've batted this around before, but it doesn't seem like git support in Designer is going to happen any time soon. What would it actually take to do this without official support?

I've worked with several revision control systems. In the end, what they care about most is files. We have files, they're stored under the workspace directory.

Would it be sufficient to create a git repository, and shove the workspace in to it so that it can be managed using git's tools? Sure, it wouldn't be as pretty and nice as doing this in Designer itself, but would it work? If not, why not?

I think the basics of it might work.


Hi David,

We have planned a feature in Designer 4.8 for supporting Git Version control for package versioning . We will be shipping Git plugin and feature along with Designer which will be used in package versioning initially.

Regards,
Vrijendra Singh
0 Likes
Highlighted
Absent Member.
Absent Member.

vkumar <vkumar@no-mx.forums.microfocus.com> wrote:
>

dgersic;2493737 Wrote:
> We've batted this around before, but it doesn't seem like git support in
> Designer is going to happen any time soon. What would it actually take
> to do this without official support?
>>
>> I've worked with several revision control systems. In the end, what they

> care about most is files. We have files, they're stored under the
> workspace directory.
>>
>> Would it be sufficient to create a git repository, and shove the

> workspace in to it so that it can be managed using git's tools? Sure, it
> wouldn't be as pretty and nice as doing this in Designer itself, but
> would it work? If not, why not?
>>
>> I think the basics of it might work.

>
> Hi David,
>
> We have planned a feature in Designer 4.8 for supporting Git Version

control for package versioning . We will be shipping Git plugin and
feature along with Designer which will be used in package versioning
initially.
>
> Regards,
> Vrijendra Singh



--
vkumar
------------------------------------------------------------------------
vkumar's Profile: https://forums.novell.com/member.php?userid=168463
View this thread: https://forums.novell.com/showthread.php?t=510908

>


This is great news! Hope the plan makes it to reality! 🙂

--
Best regards
Marcus
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

vkumar;2498448 wrote:
Hi David,

We have planned a feature in Designer 4.8 for supporting Git Version control for package versioning . We will be shipping Git plugin and feature along with Designer which will be used in package versioning initially.

Regards,
Vrijendra Singh


That's interesting. Thanks for the update Vrijendra.
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.