How to manage/create a 4D development environment for
Bruno LEGAY (11/3/08 5:47PM)
Bruno LEGAY (11/3/08 5:47 PM)
more
HI,
i am pretty new to 4D and wondering how other companies managed the
switch from being a "1 person 4D development team" to a growing number
(>1) of 4D developers ?
It all depends on your project. If all the developpers work on the
same project from the same office/location/lan, the most
straighforward group development is on 4D Server.
4D Server will allow several developers to work on a single source,
sharing all objects. It provides basic locking (an object open by one
user is locked for other users).
It is very straigforward, practical and efficient (I have worked in
the past, in v6.5, on big projets like this).
It is different from other environment approaches (subversion etc...)
where the developers does a check-out, codes, tests and commit back
to the repository some tested code (and then more unit test are
automatically performed to do integration testing). There is no diff/
merge.
4D Server will not provide change history either.
The problem is that 4D developpement is not only text source code,
but also forms (with code in objects of that form, etc...), etc...
If each developers works on individual projects with common technical
functionalities, you can organize your generic/common into components
(in v11), this is a way to share and re-use code, that can help...
It is usual to work with SVN and a single main code-base where each
developer gets his check-outs and commits back if he added his changes
or is there any other solution most teams prefer ?
I know developers expect to work with SVN, but not easily possible in
4D (yet). It should be in v12 (http://www.slicksurface.com/blog/
2008-10/beyond-4d-v11).
It is possible to export/import method source code into text files
and then use a subversion client with some code I have published
(using the API Pack plugin from Pluggers/Rob Lavaux) :
http://code.google.com/p/subversion4d
It is a two stage process :
4D <=> text files <=> repository
Where the normal situation (with java, php, etc...) is one stage
text files <=> repository
So it makes it a bit more involved...
Subversion can handle abstract file "properties" and binary files
which is good.
I have used to mostly to publish the code of "subversion4D" (eat your
own dog food) but I did not use it in multi-user/commiters environment.
And then there is the question of using subversion for other objects
(forms, stylesheets, etc...) you are getting into unknow territories.
My feeling tells me one central code-base, one central
documentation and
a stand-alone testing environment (clients & server) for each
developer
would make sense.
Sounds like a good field for a trac-installation (
http://trac.edgewall.org/ ).
You cannot compare subversion and trac, they are different things
(trac is a superset of subversion).
Subversion is a versionning system (like cvs, git, perforce, source
safe, etc..)
Trac is a projet management tool :
- interface on subversion (subversion can be configured to be
accessible via a browser anyway, take a look at the code.google
infrastructure) : http://code.google.com/p/subversion4d/source/browse/
trunk/SVN/svn_ReadMe_QuickStart.txt
- a bug tracker
- a wiki
These are the three basic tools for project management. Trac offers a
complete integrated package but you can pick your tools separetly.
My memory was that trac was geared toward a single project. We
personnaly have several clients with several projects and I found
Trac, at the time we looked at it was not suitable. So we went for a
tool (Track+) which is free for few users, but you have to buy a
licence over a given number of users.
We have set-up :
- subversion (with the apache module),
- JSPWiki (www.jspwiki.org running on Tomcat) for documentation
- Track+ (http://www.trackplus.com/ also running on Tomcat) for
bug
tracking
We could not work without a bug tracker and a wiki today.
Atlassian also provide good tools (not free though).
In the code, we paste the bug URL as comment to get the context of
the fix. It is also possible to search for the bug id. This is useful.
In the wiki, we document (among other things) the "history" of the
project (release date, etc...) this replace the "history.txt" files
(with bug URL as reference).
Etc...
Or is using GIT the way to go ?
Personnally, I don't think git will solve the issue seen above. The
debate/challenge is not in GIT or Subversion or CVS...
My personal preference is Subversion :-)
PS : Let us know which version of 4D you are using (and on which
plateform)...
HTH
Bruno LEGAY
Reply to this message
Summary created 11/3/08 at 11:41AM by Intellex Corporation
Comments welcome at: feedback@intellexcorp.com