Thursday, March 8, 2012

AS2005 Projects best practice?

Hi,

I'm currently looking for the best practice to set-up my AS2005 projects. Any help would be appreciated.

We currently need to build a lot of cubes with AS2005 and we have a lot of AS2005 developers working on this... Here are some points to keep in mind:

    Cubes will share dimensions

    Some cubes will have their exclusive dimension

    multiple developers working at the same time on the projects

Here are my options:

    Create one big project to hold all my cubes and dimensions

    This is easy to set-up and manage

    Might have some problems having multiple developers working at the same time

    What if a dimension is used in multiple cubes but we need to define distinct hierarchies for every cube?

    Create on project for the common objects (dimensions) and one project per cube

    I have the feeling that this would be hard to manage

    How can I link the dimensions from the common objects project to our different objects?

    What happens if a developer modify a dimension in the common object project ? would all the cubes using it be automatically updated?

    Create one project per cube

    This is easy to set-up and manage

    Modifying a dimension may require to modify all projects (major overhead) if used in multiple cubes

What is your take on this and how do you guys manage your AS2005 projects?

TIA,

Aiwa

I would add

that you also need to think about DSV objects. Are those developed one time

before all dimensions and cubes are started being developed or even DSVs are

going to be incrementally developed?

Eventually, are those going to be deployed as part of one database?

Are you planning to do test driven development? Will your test development be

performed in parallel with the solution development? If yes, does it mean that

any incremental work done by one developer should result in fully deployable

solution for all the cubes as part of one database, which is going to be automatically

tested on regular basis?

|||

Hi Andrew,

you are right I forgot DSV. Those should be developed before developing cubes and dimensions but change to DSV are likely to happen in the long run.

Deploying to one or more database is not a show stopper for us right now.

Yes, any incremental work done by one developer should result in a fully deployable solution.

Regards,

Aiwa

|||

Personally

i have never seen a group of people actively developing the same cube in

parallel and using a source control system. All files participating in the AS

project are in XML format. So it is possible to resolve conflicts using the

source control system you have. Some of the conflicts will be resolved

automatically. Some will have to be solved manually. But you need to make

experiments and see how it goes.

I think it

will be easier if different people work within the same project but each object

is changed only by one developer at the same time. For instance, today I would

work on dimension A and I know that nobody will touch A today. Tomorrow

somebody else could work on A but I will not. This would reduce the number of

conflicts.

Also, I do

not see big amount of manual work to do when designing a dimension or cube. The

work is mainly mental one. So, if resolution of conflicts becomes a problem

then it is possible for 2 or 3 developers make their local experiments and,

having tested locally and succeeded, get together in one room and combine their

efforts by recreating the object from the scratch while picking up the good

steps from each solution. Yes, one of the developers will have to repeat the

steps of 3 people once again, but it will not be mental work requiring a lot of

energy, but rather mechanic work.

I think you

need just try to follow your processes for a week and see how it goes.

No comments:

Post a Comment