Welcome to the CodeSmith Community!

Best practices for .netTiers integration with source control?

.netTiers

A description has not yet been added to this group.

Best practices for .netTiers integration with source control?

  • rated by 0 users
  • This post has 17 Replies |
  • 8 Followers
  • I was wondering if there are any guidelines on how to use .netTiers with source control?

    Every time I run the .netTiers templates in CodeSmit, literally hundreds of files are generated (under multiple folders MyProject.Entities, MyProject..DataAccessLayer, MyProject.DataAccessLayer.SqlClient, etc...).

    What are the best practices when working with a team and using source control:

    1) Check out all files and directories from source control before running CodeSmith?  If I do this, I then have to manually add all new files created (under each directory)?

    2) Delete all files and directories in source control before running CodeSmith?  Then add the root folder including all files and sub-folders?  We then loose the history of the middle tier source, but is it really important?

    Any suggestions will be appreciated.

  • What source control system are you using? We use SVN, which allows us to generate over the top of the existing files, commit the changes to already existing files, and add anything new via the Tortoise commit window. We did run into various issues when multiple developers were generating over the top of each other, especially when working from local development databases and not a common development DB server. To get around this, I have assigned myself as the designated generation monkey ... Cool

     

    One tip when using any source control system: you'll run into fewer conflicts/changes in your base classes if you set "IncludeGeneratedDate" in the netTiers Code Smith project to false. When true, all it does is include the date and time the files were generated in a comments section at the top of every class.

     

    Hope this helps!

  • I'll be watching this post with interest.

    We're using Microsoft Team Foundation Server 2008, and we're running into the same problem.  Currently it's a case of checking out EVERYTHING, regenerating, and then checking everything back in ... including checking in all the new files.  That said, we can bulk check-in the new files, we don't have to go into each subdirectory and manually check them in.

    Still, this does wreak some havoc with the development team.  We need to get everyone to check in whatever they're working on, and then sit tight while we muck about with regeneration.  Definitely not ideal, especially considering the team is geographically disparate and it's not uncommon for regenerations to happen at odd hours and/or for people to keep items checked out overnight.  But maybe that's a internal issue we need to look at.

    I wonder if there's a way to regenerate to a separate folder structure, then do some kind of diff/compare to the local copy of the controlled source, and have the changed files automatically checked out, replaced, and checked back in?

    I'm open to suggestions as well :-D

    Tok

  • We are using SourceGear Vault - it's pretty good and like SVN allows us to check-in changes to existing files and add new files as well.

    I guess the first question we should ask ourselves is:

    1) Should there be one centralized SQL database for all developers?  .netTiers would generate the code from this database.  The problem with this approach is that while changes are made to the schema, code breaks.  In addition, all developers need to sit and wait while changes are being made (as described in this thread).

    2) Alternativaly, should each developer have his/her SQL database?  .netTiers would generate the code from each private database.  In this case, a developer would check in the code only after the SQL schema changes are done.  In addition SQL changes should be synched to a centralized SQL database from where each developer can synch their personal DB (by the way SQL Compare by Red Gate is an excellent tool for this).

    If we go with option 2, there's no need to check-in the tiers generated by .netTiers - every developer would just re-generate the tiers as needed.  We would only check-in the code generated by .netTiers once: after code freeze and just before we are ready to build and deploy to QA/Staging.

  • Well, we use Team System as well.  Here is what we do to generate:

    1. Open the Solution that has all my nettiers projects.
    2. Check out the files from the solution
    3. Close the solution
    4. Run nettiers
    5. Open that same solution.  It should prompt you about the source control, just select use solution binding.
    6. Check in from there.

    Now, for new files that were added:  Different source control providers do this differently.  For Team System, new files added to the solution outside of Visual Studio are not added directly to source control.  You have to add them in Batch.  I have a batch file that I check into source control that uses the power tools to batch add all the files.  It is really simple using TFPT.  I can share this if someone wants...it is just 4 lines, calling TFPT 4 different times for each sub directory. 

    When using Source Safe, I believe all new files are automatically added.  Now, other Source Providers may act differently.  You would have to talk to the source control provider to see if this is how it works and if there is some way to mass add files into source control.

    Now, as far as database goes.  Our developers use a common DB.  We have a DB for each working branch.  All code is generated for that branch against that DB.  We try and make sure that only 1 developer is generating at a time to just avoid conflicts.  Makes it easier.  Having a DB for each developer would be tough.  If they all have different schemas especially.  You could do it, and once they merge there code into a common branch or DB, you could regenerate.  it may not sound as bad as I make it out, but it might cause some headaches.  I don't like my developers having different DB's.  I want the communicating about changes.  So if they are changinig stuff, they better tell people.  If someone really needs to change alot and doesn't want to effect everyone, we can branch the code, and let him use his own DB for his branch.  Then, once he merges back into the main branch, we will merge his DB changes and always re-generate.  We try and avoid merging generated code.  It always causes unecesary conflicts.  With our strategy, we generate code x number of times daily with very little trouble.  It works great in our environment.

    Feel free to comment and ask away!

    jeff

    ----------------------------------------------------------------------
     Member of the .NetTiers team | Visit http://www.nettiers.com
    ----------------------------------------------------------------------

  • Dude, if you have to generate codesmith over and over again, go back to the white board and discuss your acrchitecture/design with your team, there's gotta be something terribly wrong. Or maybe you guys are using way too much sp's... and most people know how much i love sp's...lol. (;

     

    Seriously, at my company theres the Codesmith/.netTiers monkey who's responsible to make any changes to the script and to generate it, yes, meeeee!!! I check-out everything and check back in, but hey, I'm using Source Safe (which sucks, by the way). Any other source control you have to add new files 'manually'.

  • Thanks Guys, all very interesting.

    Jeff, I'd love a copy of that little script, if you have it available.  We're only just getting into Team Foundation Server after using SourceSafe for many years ... anything that gives us a leg-up is greatly appreciated!

    I'm leaning heavily toward's Jeff's method, simply because (1) he's using the same source control platform as us, and (2) he's a netTiers team member, so one would expect he knows what he's talking about! :-D

    Our team does a lot in agility/scrum, and we find that we probably rebuild the netTiers code against the database twice a week or so.  The frequency of the builds / check-ins really doesn't have much relevance to the original question, ie what's best practices for netTiers and source control.  If your project is large and the database is relatively static, I could see value in whiteboarding the issue, addressing the question of why the netTiers later needs constant regeneration.  However, smaller (ie sub 100 table) projects with agile development teams just need effective source control integration ... "build early, build often" will sort out the schema quickly enough.  Agile development has given us a remarkably quick time-to-market, which has meant a lot more work for us.

    Not checking in the netTiers code until QA/Staging isn't really an option for us either.  We've placed most of our validation and business logic deep down into the netTiers code, making it a true on-stop shop for our Winforms, Webforms and Compact Framework apps.  It's those layers that see the most code churn, as new rules etc are implemented, which aren't handled by the general netTiers validation code.

    The RedGate package I used a couple of years ago.  Very nice for re-syncing database schemas.  I might google source control for database schemas ... there's probably something out there useful.  Knowing my luck, it's probably in TFS and I just haven't found it yet!

    Thanks all.  Will take a closer look at the issues tonight.  Jeff, if you have that script handy ...

    Tok

  • Toksic:
    Thanks Guys, all very interesting.

    Jeff, I'd love a copy of that little script, if you have it available.  We're only just getting into Team Foundation Server after using SourceSafe for many years ... anything that gives us a leg-up is greatly appreciated!

    Jeff, can you post that script in the forums, I'd like to sneak a peek. (;

    Toksic:
    I'm leaning heavily toward's Jeff's method, simply because (1) he's using the same source control platform as us, and (2) he's a netTiers team member, so one would expect he knows what he's talking about! :-D

    Yeah, everybody loves Jeff... lol. But you're absolutely right to follow whomever has an environment that looks like yours.

    Toksic:
    Our team does a lot in agility/scrum, and we find that we probably rebuild the netTiers code against the database twice a week or so.  The frequency of the builds / check-ins really doesn't have much relevance to the original question, ie what's best practices for netTiers and source control.  If your project is large and the database is relatively static, I could see value in whiteboarding the issue, addressing the question of why the netTiers later needs constant regeneration.  However, smaller (ie sub 100 table) projects with agile development teams just need effective source control integration ... "build early, build often" will sort out the schema quickly enough.  Agile development has given us a remarkably quick time-to-market, which has meant a lot more work for us.

    Dude, we do a lot of scrum in our team and going to the white board to discuss database changes were never a bad thing. I just don't trust one person idea, even if it's mine, I like to hear what other have to change. A poorly designed database can destroy your application if you have a little traffic. That also reduces the number of times you re-generate .netTiers (a least in the projects I've participated)

    Toksic:
    Not checking in the netTiers code until QA/Staging isn't really an option for us either.  We've placed most of our validation and business logic deep down into the netTiers code, making it a true on-stop shop for our Winforms, Webforms and Compact Framework apps.  It's those layers that see the most code churn, as new rules etc are implemented, which aren't handled by the general netTiers validation code.

    Just take care to keep stuff where they're supposed to be. Your business logic should be somewhere in your services. I don't like to pass the responsibility to stored procedures, some people do. Long discussion, not worth getting into it.

    Toksic:
    The RedGate package I used a couple of years ago.  Very nice for re-syncing database schemas.  I might google source control for database schemas ... there's probably something out there useful.  Knowing my luck, it's probably in TFS and I just haven't found it yet!

    Thanks all.  Will take a closer look at the issues tonight.  Jeff, if you have that script handy ...

    Tok

    If you find a way to source control schema's, please let me know. And just one question. Which tool are you using to model you database? I need one, a good one.

     

  • We are in huge development mode.  We are asked all the time to add new functionality to the system and create more of the system.  Our data model is nothing what it was 6 months ago.  It is an evolving work.  Some of it is stored procedures, some of it is data model.  Some of it is adding a View or Index to get the right data the most efficient way. 

    We operate out of 3 databases: 

    1. Has 320 tables, 65 Views, 248 Custom procedures
    2. Has 100 Tables, 18 Views, 66 Custom procs
    3. Has 20 Tables, No Views, 1 Custom proc

    The top 2 change with each release.  They are generated often.  We don't generate n times everyday, but we can, and we have.  We more than often than not I would say generate 3 times a week, for each DB.  I don't think we have that big of a shop either, but like I said, we have a fast changing environment where we are in a very hurried development mode.  If we did more maintenance work, we would generate much less.

    Anyway, I am sure you will love the custom proc counts lol.

    jeff

    ----------------------------------------------------------------------
     Member of the .NetTiers team | Visit http://www.nettiers.com
    ----------------------------------------------------------------------

  • Toksic:

    The RedGate package I used a couple of years ago.  Very nice for re-syncing database schemas.  I might google source control for database schemas ... there's probably something out there useful.  Knowing my luck, it's probably in TFS and I just haven't found it yet!

    You want to try early on to include Team System for Database Professionals.  I really regret not starting out with Team Suite.  Once you purchase something like Team Developer, you can't upgrade.  You are out that cost.  I am trying my hardest to get this through management.  We currently are using Res Gate Sql COmpare to do our merging but this product doesn't "merge" DB's.  It replaces one with the other.  It rights a merge script, but if you made a change in both DB's, one is overwritten with another.  In Team System, if you make changes to the same object in both branches, merge the branch, it "merges" the changes.  If you use the Database Professionals product, it actually merges and generates the correct scripts to deploy against.  I have not used this, but in theory, this would be the bomb.  We do alot of branching and merging in our shop.

    1.  Are you using Team Suite for all developers?  If so, they have access to Team System for Database Professionals. 

    2.  If you have one central DBA that is doing your DB changes, get them using the Team System for Database Professionals.

    But you are right, Red Gate is a must if you don't have something like I discuss above.

    jeff

    ----------------------------------------------------------------------
     Member of the .NetTiers team | Visit http://www.nettiers.com
    ----------------------------------------------------------------------

  • cd Seminole.Gem.BusinessEntity
    tfpt online /adds /recursive *.cs
    cd ..
    cd Seminole.Gem.DataAccessLayer
    tfpt online /adds /recursive *.cs
    cd ..
    cd Seminole.Gem.DataAccessLayer.SqlClient
    tfpt online /adds /recursive *.cs

    This batch file goes in the Generated folder I select in Codesmith.  I go into each directory of the projects I use from the Generation and pend the adds.  This won't check them in, but it will pend the changes.

    You will just need to download the powertools from MSDN, make sure the directory where it installs is in your path.  There are alot of good tools in here that are really handy.  I would read up in the powertool documentation.

    jeff

    ----------------------------------------------------------------------
     Member of the .NetTiers team | Visit http://www.nettiers.com
    ----------------------------------------------------------------------

  • The only thing we keep in source control are the generated DLLs.  We don't use the generated solution in our development so we don't have to deal with all of those files.  Our process (in a nutshell), is this:

    1. Developer checks out necessary database script, makes changes and checks back in
    2. Build server running CruiseControl (continous integration) monitors VSS and sees change
    3. CruiseControl checks out DLLs automatically from VSS and runs database build scripts
    4. Generates DLLs from command line after database builds
    5. CruiseControl checks back in the DLLs that were re-generated
    6. That triggers our web application to re-build via CruiseControl that references the DLLs from the database project

    There's a lot more to it but the nice thing is that it's all automatic and we get notifications right away if something goes wrong (via CruiseControl).  All the developer has to do (12 minutes later) is get the latest in Visual Studio and they'll have the updated DLLs.

    Nobody having to check stuff in, nobody having to handle the re-generation.  It's all automatic!

  • We have a central db and I used to be the netTiers gen monkey, but this caused problems when I was out of the office. 

    So awhile ago we set up a separate machine with a dedicated netTiers user on it to do the gens. When a gen is needed we remote desktop onto the machine (it's set so only 1 session can be running) and do the gen and checkin from there. We have over 250 tables and frequent changes and everything works well.

    hth

    swin

    ------------------------------------------------- Member of the .NetTiers team -------------------------------------------------
  • After reading this, I would love to see us implement source control support that CodeSmith 5.0 provides. It would really solve the check in and checkout headaches. But there’s a downside to this, I haven't tested this but I’m pretty sure we would then need two branches, because the way it would need to be implemented isn't available in CodeSmith Standard ("Multiple Outputs").

    Thanks

    -Blake

    Blake Niemyjski
    CodeSmith Tools, LLC. Software Development Engineer
    Blog: http://windowscoding.com/blogs/blake/
    .NetTiers team | Visit http://www.nettiers.net

  • Yea, and I am sure you are using the MSSSC provider?  Team System has one, but I haven't had much luck in using it.  We used it within Management Studio for a while and it was horrible between multiple branches.  I would really have to play with it to see if it works ok with Codesmith.

    The steps seem long, but they are simple to do, and really don't take that much time.  Considering the time it saves you from having to write all that mundane code, I can't complain.

    ----------------------------------------------------------------------
     Member of the .NetTiers team | Visit http://www.nettiers.com
    ----------------------------------------------------------------------

Page 1 of 2 (18 items) 12