Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

[tomdigate]

I have a team of 5 AlphaAnywhere developers that I want to work on the same project. How can I setup A5V12 to enable each developer to work in the same project? What source code control methods are available for use with A5V12?

Example use case: Each developer might be working on several UX components related to a subsystem of the total web/mobile application. We want to use a Source code control system to manage the total code base while enabling each to do development and unit testing. We use a DVCS (Mercurial) for our Java-based development and would like to continue using it with A5V12.

Looking for best practices on how to set this up.

[Ted Giles]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

Are you using Agile as an approach?
Not sure that AS lends itself to a collaborative development that easily.
Checking in/out pages will be difficult.
You might need several apps, all separate which will be pulled together as the dev progresses.
One thing is certain. You need an agreed spec., and agreed terminology/standards. It helps if you know the abilities of the team as well.
I've seen some spectacular collaborative cock ups because the standards - like font size - weren't agreed and documented up front.

[mikeallenbrown]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

This is a thread that I'm interested in. I've worked in Alpha since version 8 and it seems geared more towards a single developer and not a group effort.

I look forward to seeing more replies here

-Mike

[Skipperj]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

My team of 8 looked hard at how it could be possible and found no good way for us. I would be interested in seeing more on this as well.

[kiwibruce]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

We are just getting to having a couple of developers needing to work on the same Alpha Five project.
I would be really really interested in peoples experiences.
What are the various strategies. do anyone have tips etc that they can share?

Bruce

[jkwrpc]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

Bruce

I worked with a colleague in the UK on a simple A5 project. There was no way for us to pass to deal with others versioning issues. It came down to him working on certain bits of logic forms or reports, and me bringing them into the main project files. In some cases I was able to import them , in other others I had use cut & paste to recreate his work. Even then it was not without issues, if you had several developers it would be extremely difficult I think.

[Ted Giles]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

OK, these are just a few thoughts. Not saying they will work in all cases, but they seem to have for me.
1) A decent specification and means of updating the spec. I use UML2 "Use Cases", Activity Diagrams and a logical process flow (visio) to describe the application if is a billable one. Nail it and do it. Use some form of Change Control.
2) Database design. This is probably the most important part as it will affect how Alpha grids and forms will run. I use a number of proprietary - and free stuff - like Visual Paradigm for requirements capture, TOAD for design work, and Visio for describing the logic. There is a lot out there to choose from, but the outcome is worth the effort.
3) Common Routines. If I am working with another person, I don't want us both to be designing the same scripts in different ways. In the old days, these were called Standard Functions. So menus would be pre-developed and just used, and not recreated. So would a lot of the base functionality.
4) Common approach. Create a standard framework in Alpha Preferences and don't let anyone use anything else.
5) Control methods. Alpha will require a separate instance to enable users to work on their bit, so lets say we have 4 screens - all different - running of one table or a set. Lock the ones you are happy with by password protecting them. The developer will only be able to use the ones allocated to them and unprotected.
6) Repository. Depending on your budget, a decent folder structure is helpful, so each person doing a bit of the work can manage their own space. I also use Drop Box to store some code, and that is easily accessible from anywhere.
7) Control Process - including estimating time to complete, (see my free software). When a job is given to a developer, they will need the bare minimum to do their part. Say 3 developers and 6 screens. Dev1 has the Db + 2 screens to develop, Dev2 has Db + screens 3 and 4 to develop etc. The job of the Fat Controller (http://en.wikipedia.org/wiki/The_Fat_Controller) is to bring all this together into the developing application.
8) Suggestion. Read up on the files types in AS and when they are used. Then you can import the bits you need and not have data overwritten.
9) A Backup and Restore repository. You can get back in AS, but there is nothing like finding you have inadvertently overwritten the code by mistake - they do happen - and realising you have not got a "before" image.
10) Testing. You need a test plan. It's up to the Program Manager whether to carry out regression testing at every consolidation, or wait and do it weekly/monthly. Leaving it until it's all complete will drive you nuts.
11) Responsibilities. Suggest you don't get involved in fixing someone else's bugs, and you need a way of controlling the bug resolution. http://flyspray.org/doku.php is a good one and free. I've used it on very big developments lasting years. (SQL/SharePoint/WinForms).



Edit:
John beat me to it. See item 7 above.

[Skipperj]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

Alpha does not seem to be like other offerings where different parts of the complete application can be built in modules. I won't give named examples because this is all about AS.

It would be nice if one could work on db, two could work on user interface, three could work on visitor interface, four could work on accounting, five-seven could work on other sections and eight could oversee(coordinate). This is the way we normally do it. All are charged with making sure their part works with the needed shared variables, fields, db's, etc and kept straight by eight.

Each section of the above is actually seperate applications that are connected at runtime(web space).

I still cannot see where that can be done with alpha and achieve good results.

Hope to hear more and maybe a light will go on? We only do web and as would be used for what we consider to be smaller apps for companies/corporations that will accept AS software generated applications and don't mind the costs of upkeep versus extra development costs where applicable.

[christappan]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

There's not anything I know of for documenting code changes/tracking it, but some of us use Dropbox so that we each have updated components. I just use it with one other developer, so I'm not sure how well that would scale, but it's an option.

[mikeallenbrown]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

Google Drive is another good option for sharing components and for backing up your work. It is way too easy to overwrite someones work when working on the same project.

-Mike

[Ted Giles]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

You could control all this with an AS application.
I'm Dt fan, but using that, you could manage the Zipping and sending of files quite easily.
Use the product to manage the process?

[kiwibruce]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

Hi All,
Here is an answer I got from Jerry at Alpha when mentioned this thread. Richard asked me to re-post it here

Bruce

There are a wide variety of source control systems you can use. Internally we use GIT and I have used CVS on a number of projects. A system can be a simple as a master copy on a shared drive or folder, or a more complex system such as GIT that allows merging and branching. With such a range of solutions, we can't make a recommendation as typically a development group will use whatever system or method they either already have in place or feel most comfortable using.

The only areas were source control doesn't work very well is merging or comparing changes in components as they are saved as binary, and changes made to the work space data dictionary such as special scripts or functions that may be published as an AEX file.

In the case of components, comments added to the source control commits about changes made are very useful. If the comments are clear, multiple developers should be able to track the changes even if they can't directly compare the source code.

In a web app, typically very little is saved in the workspace data dictionary if the web components use AlphaDAO. Reports, letters and labels for SQL sources originally were stored in the dictionary, but we now allow building those directly in web projects, so they can be managed by source control very easily

The workspace data dictionary library can also be converted to a file system if it uses scripts and functions that may be published in an AEX. In a file system, every layout, script and function is saved in individual files in special library folders. This makes working with source control much easier as a single function exists in a single file and can be updated without impacting any other code.
Jerry Brightbill

So has anyone got experience using GIT or CVS ? I would love to know if one is better than the other in relation to Alpha.


Bruce

[tomdigate]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

We use Mercurial which is a Distributed Version Control System (DVCS) similar to GIT. Both allow simultaneous file editing and rely upon the "Merge" to resolve conflicts. GitHub and BitBucket both provide web-based repositories for use as your Version control system.

The most recent response from kiwibruce says that there is a way to convert the workspace data dictionary to a file system. Can anyone explain how this is done? This would help by making the project more granular.

It is unfortunate that Alpha doesn't have a textual representation of components to enable comparison between versions and hopefully resolve merge conflicts. The Version system would be able to tell you that someone replaced it while you worked on it but all you would have are the comments to determine whether to replace the one in the repository with your more recent version. It would be nice to be able to see the changes made.

[Ted Giles]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

It is unfortunate that Alpha doesn't have a textual representation of components

You have a copy of A5Doc I presume?

[kiwibruce]

Re: Team Development using AlphaAnywhere--- How to set it up? (Best Practices?)

You have a copy of A5Doc I presume?

Hi Ted,
A5Docs looks great except I take it A5Doc is for the Alpha Desktop projects. Does it document anything in the web control panel?
As I only do Web projects so have absolutely no objects in the old control panel.

Thanks!