This topic is locked

Team development

9/6/2016 2:18:30 PM
ASPRunner.NET General questions
Pete K author

Is anyone using any of the xRunner products in a team environment? It seems best suited to lone wolf developers but I'm thinking of giving it a try for a small dev team (3 members). The challenge is figuring out how to collaborate using a code generation product. There doesn't seem to be any baked-in way of implementing source control or other collaborate concepts, but that's understandable given the nature of the product. So it might be a challenge to work this out.
I was thinking about the various tasks associated with developing a usable product and quite a few are done independently of xRunner or at least outside the IDE itself. For example:

  • creating mockups
  • designing the database schema
  • writing SQL functions and/or procedures to implement business rules
  • writing asp.net code to be referenced from within the generated app
  • writing user documentation
  • QC testing
  • deployment issues



And so on. Maybe one member of the team could be the designated ASPRunner.net person who generates iterations of the app while the other team members work on these other areas. I'm not sure -- just thinking out loud here.
Anyone have any experience or ideas?

jadachDevClub member 9/6/2016

I have a team of 3 as well. Mostly, we would work on a project solo, but will always be communicating to the group what is being done. We have a range of skill sets, so one may be more knowledgeable in SQL and one may be more knowledgeable in JavaScript. We help each other, then we all take credit. If someone is struggling, I will take a copy of the application and run it local on my machine to try and help and educate.
If you really think about it, this product is so self-contained and intuitive, that the need for source control is overkill in my opinion. In our environment the SQL Database server and all it's linked servers, jobs, permissions, etc is probably our most complex environment. So we can definitely tag team with one working the front end with ASPR.Net and one working the back-end with SQL Server Management Studio.
Once a project is in production, we keep a copy of the app folder in a safe place. if revisions are required, one of us will make a copy and work with that. We ALWAYS need the source files of the production application in sync.
Hope that helps. Not very Microsoft-ish <img src='https://asprunner.com/forums/file.php?topicimage=1&fieldname=reply&id=80236&image=1&table=forumreplies' class='bbc_emoticon' alt=':)' />, but it works for us.

Pete K author 9/7/2016

That is very helpful! Could be a template for how we wind up working. I may lean on you for advice from time to time. This will be my first time leading a team.

jadachDevClub member 9/7/2016

Call me any time. i think you have my cell. if not, email me and I will send.

Pete K author 9/12/2016



Call me any time. i think you have my cell. if not, email me and I will send.


Thanks!

T
Tim 11/11/2016

Hey guys,
I'm glad to see this discussion. We currently have a few of us working on the SQL database side of things, but I have been the only one doing the front-end ASPR work. This might be changing soon and I'm trying to think through how to work collaboratively on ASPR projects. What you have laid out is what I currently do and it works well for me. That is, I keep a master/production version of the ASPR source files, and then make a copy of them to work on changes. And then, when I'm satisfied with the changes, I simply delete the old "master" copy and make the copied files the new master source.
What I'm worried about is if 2 people make copies of the production version and begin to work on different new features, how do you pull it all together in the end?
I agree that a true, full-feature source control is probably overkill, but it would be nice to make a copy, work on it, and then merge these changes back into the "master" version. Is anyone doing something like this?
Thanks,

Tim

Pete K author 11/14/2016

I don't have any answers for you Tim, but my team is going to be coming together in the coming weeks and I'll be trying out some strategies. I'll try to remember to keep this thread going and post on our progress and lessons learned.