mibuso.com
Home› NAV/Navision Classic Client
Options

More than one developer on one project

TRSOEgroupTRSOEgroup Member Posts: 37
edited 2005-05-11 in NAV/Navision Classic Client
i'm reading for the development exam, and i will have it this wednesday..

one of the topics i can't find anything about is more than one developer on one project, i know we can use some source safe program, but what's the "Navision way" to do it...

what i'm trying to say is, what do i need to know about it for the exam?

:?: :-k

Comments

  • Options
    janpieterjanpieter Member Posts: 298
    * Dont edit the same object at the same time.
    * The object cache may result in opening an older object. Your colleague then gets to loose it's changes.
    * Even better : try if possible to let each developer work in different object ranges.

    I thing source safe integration is rarely found in the Navision world. I have developed an integration and hope to make it available within a sort while if our management lets me do that. But it isn't a microsoft way.

    I know MBS Navision in the Netherlands work with sourcesafe but they have developed some tools arround it and still have to manually export obects. I don't think you can really call it an intergration.
    In a world without Borders or Fences, who needs Windows and Gates?
  • Options
    guidorobbenguidorobben Member Posts: 157
    We add our initials to the version list of the object we are editing. So before we modify an object you have to check if somebody has locked the object with his initials.

    Guido
  • Options
    krikikriki Member, Moderator Posts: 9,090
    That works fine enough when developping at the same place. In that case when you want to change/add an object, you can directly ask the others if that object is free. To be sure you have the latest version, it is best to close the DB and reopen it before editing the object.

    In general I have a more complicated situation. I work at Milan, and other developpers are at Venice or Genova (=Genua?). Because of the responsetimes (even with terminal server) it is not possible to work on the same DB. So each developper has his own DB.
    How to handle this:
    I gave each developper a range of objects/fields which are his. Eg: if he has to add an object or a field in an existing object, he has to do it in his range. And also it is best that a certain field X has the same ID in ALL the objects where it is used. So for every new field that has a new function, I use a unique field-ID.
    If someone wants to change an object, and he has some time, he can send an email to the others with the question if it is free (and if he has the ultimate version (DATE-TIME of the object)). If it is urgent, he can call.
    Every time a programmer has finished a part (eg. add a new field in customer card and Sales Header and it's posted tables), he has to send the objects to the others who have to import it. Every programmer has to keep the fob-files for some time, in case something goes wrong, you can still find the old object. The fob-files we create have the following format:
    "PROJECT DB-version DATE TIME some comment" (Eg. "EXAMPLE 3.70A 20050511 1351 Point 111"). DATE TIME : when the fob was made. This makes it easy for the others to see in which order to import all. (In case one of them has accumulated some fobs to import)
    "Point 111" : this refers to record in an Excel-sheet in which all things to be developped, bugs, ... are listed with some extra info (Unique ID ; who described the functionality/bug ; who has to solve it ; deadline ; description ; if the programmer has fixed it ; if the anayst tested it ; ...).
    Once a point is completely fixed and tested, I remove it to another page. This excel sheet has to be maintained by the main programmer or the project-leader. And from time to time send to all the persons involved (also the testers). When the analyst tested a point he has to send the result at the main programmer to update the excel.
    At the end of the day, every programmer has to send the work he has done to all the others, BUT ONLY if the unfinished work does not block the other functionality. This can serve if (see the example above) if the customer-card is ok, but not yet the Sales Header. So another programmer can already use the customer-card.
    If it happens that another programmer has to change the same object and cannot wait, he can start it BUT HE HAS TO DOCUMENT WELL WHAT HE CHANGED BECAUSE AFTERWARD HE HAS TO MERGE THE OBJECT!

    Documentation section : everything has to be documented with date, added fields, added functions, added menubuttons/menuitems,... , some description of the point (with the unique ID), name of the programmer (to know who's *** to kick if something is programmed badly). In the version-list we put a comma-seperated list of the points. If the version-list is full, you can delete the oldest or the less-important points.

    From time to time (once a week, once a month, whenever you think it is needed) it is necessary to confront the versions. Every programmer has to send all the changed objects of his DB to the main programmer who checks the versions.
    To do this quickly it is important date the Date-time of the object is maintained. Eg. if you change an object and later you decide that was not necessary and delete the changes again, there are 3 possibilities:
    1) re-import the latest version
    2) put in documentation-section you saved the object but didn't change it
    3) give it the date-time 01/01/01-01:01, meaning any other version is more important than this one.
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!

Sign In or Register to comment.