How to develop with multiple developers?

[AngusETM]

Hi all,

Is it possible for multiple developers to run GEDI UIs on the same servers at the same time to perform development? We've tried by logging in to a server with two different users and running two GEDI UIs, however both UIs appear on the same user, not one on each user. I think this is probably not possible but just hoping to check.

Otherwise, how do you handle development with multiple developers? Do you run separate WinCC OA instances on each developer's machine, then track and merge files with GIT, GITLabs, etc? Or some other method?

Regards,

Angus

[leoknipp]

At ETM every user/developers has its own project (with the same language settings) and the files are checked in to a GIT repository.

Another possibility is to run a server and to connect with a client UI to the server project.
If the last project path in config file refers to the project directory at the server the files are saved at the server if they are edited in GEDI.

In this case you might run into problems if the same file is edited by different users at the same time as changes by one user are overwritten by the other one.

Best Regards
Leopold Knipp
Senior Support Specialist

[RudiKreiner]

What we do is to create a separate project path for each developer to which he checks out panels (also scripts and whatever else he wants to change) and start the UI including GEDI with the following option to use this as the top level project path, like this:

+config C:/Users/kr/BmsProjectManager/Standard/config/Standard_local/config/config_work

That additional config file just needs these entries:

[general]
proj_version = "3.14"
pvss_path = "C:/home/pvss/3.14"
proj_path = "C:/Users/kr/BmsProjectManager/Standard"

That way we all share the same project, which may cause problems if different developers want to manipulate the same datapoints in different ways,
but has the advantage that each user can work on his panels and scripts independently and check them in (and with a post-commit script copy them to a project path common to all users) when he is finished.
We use SVN, not GIT, which allows us to lock files to reduce risk of merge conflicts. That works OK if the development team close together and not too big.

[AngusETM]

Thanks Leopold and Rudi. At the moment due to some people working remotely we've decided to just copy new panels into a master project, this seems to be the simplest method for the moment but we might move to something more advanced down the track.

[mhargreaves]

Hi Leopold - could you explain how the workflow works with the GIT repository - what should be checked in and how do the other developers get the change?

I am thinking more about developers making changes to datapoint types or datapoint config values rather than panels and project config files.

For example one engineer needs to update a datapoint type or (say) a peripheral address configuration.

At the same time, on a different PC, another engineer is updating a different datapoint type or different config.

How can both changes be checked in/out of a repository so that someone can then check out a database with both changes included?

We have not yet worked out a way of doing this. so at the moment, each of our developers make a change on a single machine and then the whole database is checked into our source control repository. We were thinking there must be a better way of working.

[leoknipp]

If you are using a central server where the WinCC OA core processes are running and every user only starts a user interface you will have only one database and all users will see the current information.

You can also use the approach ETM is using for the standard database.
If you create a new project using the project administration an empty database is created and afterwards ASCII files with the standard datapoint types, datapoints and configs are imported.
When we do changes on the standard the ASCII files are modified. As the ASCII files are textfiles you can merge changes made by different users.

For your datapoints types, datapoints and configs you can create own ASCII files which can be imported automatically when creating a new database using the tool WCCOAtoolCreateDB and the option -importAscii listfilename

If you want to check in a complete database you have to keep in mind that this database might contain some original values, pending alerts, historical alerts, ....
When you use this database then as template for a customer project it might contain information which is not related to the customers project.

Best Regards
Leopold Knipp
Senior Support Specialist

[mhargreaves]

Hi Leopold
Thanks for that.

I think the approach ETM is using for standard database sounds good for us. Is there any more information available on the tool WCCOAtoolCreateDB?

Mark

[leoknipp]

You can start the tool with the option -help to get the information which parameters are possible.
To get a new standard database the tool needs to be started only with the option -proj to specify the project.

Best Regards
Leopold Knipp
Senior Support Specialist

[mhargreaves]

Thanks - and does the ascii file to be imported have to be in a particular format - is dpl OK?

[adaneau]

Hi Mark,

We are doing the same approach as Leo explained, using WCCOAtoolCreateDB. You can use standard dpl, it is perfectly fine. We embedded it inside a bat file so it is easier for the developers to call it when pulling from GITLab.

BR
Alex