11/22/2024 2:56:40 PM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss general administration topics for SalesLogix (including LAN & remote topics). View the code of conduct for posting guidelines.
|
|
|
|
Server Setups
Posted: 18 Apr 06 9:24 PM
|
fiogf49gjkf0d Ok so we just bought a couple new servers...one for SQL, one for KnowledgeSynch, etc. I was wondering how people have their servers set up for development/testing/staging/live. Do you use a seperate dev server? Do you do development on a different database on the same server and then bundle it up? How often do you refresh your dev database? Basically I'm just looking for ideas to make our dev process more streamlined...its kind of every man/plugin for themselves right now. |
|
|
|
Re: Server Setups
Posted: 19 Apr 06 1:50 PM
|
fiogf49gjkf0d I would always stress using a dev db on a physically different server for the small chance that someone will be lazy and just switch to the production db since you pretty much already have access to the machine.
I'm a one-man army, so my development db is on a Virtual PC OS that I run from my laptop. All development starts there, with very little lapses in working on the production server directly. Whenever I make a change, I create a new version and update the bundle version to the highest version number of plugins. When I feel testing is completed I then move the bundle out of VPC and onto the production server. I update the bundle within Administrator applying only the changes that were made.
My dev db was built from the blank provided when SalesLogix was installed, so it is completely different than our production server. This is to make sure that bundles have all the data they need to install in any database. I also keep this database as clean as possible sometimes even starting over from a new blank when the need arises. While the data differs between databases, anything that is broke in production functionality wise generally is broke in the plugin and has very little to do with the data itself.
To keep bundles simple if table definitions change I usually do that manually. The bundle has the updated table but applying it to production would wipe out the data. I could always export/import the data back in which would probably be slightly faster than editing each table manually. The end result is that each bundle can be applied to a fresh database without any special manipulation.
Personally I would never use a staging or testing database as it adds a layer of complexity I don’t need. While I would test on a dev db as much as possible, I always forget something minor that would force me to go back to the dev db, make the change, bundle, apply, rinse, and repeat. It’s definitely good to test customizations against existing data it will use versus newly created data but I find that I generally think about testing data inconsistencies better when I don’t rely on production values.
When I think about all of this, the implementation is really going to center around what you can do. Does each dev have the sales client on their machine? If so a dev db there might not be bad with a centralized testing database to make sure every customization plays nicely together. If not, remoting into a central db to work would be ideal. Are you separating tasks adequately so that any include scripts from user A aren't going to be screwed when user B makes a change? Bundles don't have newer versions unless you specify them so this is something a testing db could catch though you would have to code, apply, code, apply since you couldn't do ANY testing on the dev db. There could be more scenarios I've missed but this should be a good starting point. |
|
|
|
Re: Server Setups
Posted: 19 Apr 06 2:47 PM
|
mixing lexapro and weed mixing adderall and weed fiogf49gjkf0d Assuming you dont have OS dependencies and all your apps can run on one OS you could simply have 2 virtual machines - Dev and Staging (test, deployment, whatever you want to call it). Each virtual machine would have SQL Server, SalesLogix Server, KnowledgeSync, SalesLogix client apps, etc.
Originally posted by Jeremy Brayton
I would always stress using a dev db on a physically different server |
|
I agree - do not use your production sql server for non production databases. We have a dedicated SQL Server for all of our development and staging databases but we are a business partner and have many customer databases to support. This probably does not add much value for you. Also note that when you create your dev and staging databases from production, you must update the sync, attacments, and library paths so that you do not have collision with production. I will not outline that here as I believe it is documented elsewhere.
Originally posted by Jeremy Brayton
Whenever I make a change, I create a new version and update the bundle version to the highest version number of plugins. When I feel testing is completed I then move the bundle out of VPC and onto the production server. I update the bundle within Administrator applying only the changes that were made. |
|
I suggest having a staging environment. Jeremy's approach assumes that mistakes will not be made when building deployments. This is a common and big mistake IMHO. I also feel that the staging environment is where user acceptance testing should take place. You need someone to double check that you did not miss something during your deployments (not just you).
Originally posted by Jeremy Brayton
My dev db was built from the blank provided when SalesLogix was installed, so it is completely different than our production server. This is to make sure that bundles have all the data they need to install in any database. I also keep this database as clean as possible sometimes even starting over from a new blank when the need arises. While the data differs between databases, anything that is broke in production functionality wise generally is broke in the plugin and has very little to do with the data itself. |
|
Use a current copy of production when first starting out. Data is VERY important in a database front end solution. Users need to see what they see every day when testing your customizations. More importantly, your customizations need to be tested against real data. This also ensures you are starting with the latest and greatest plugins from production (as well as schema, picklists, lookups, etc). Why expend a single minute of effort trying to port production customizations to a blank database when a restore of production gets you there immediately?
Originally posted by Jeremy Brayton
To keep bundles simple if table definitions change I usually do that manually. The bundle has the updated table but applying it to production would wipe out the data. |
|
Schema changes must be treated just as any other change. Maybe Jeremy can elaborate on what he means about "wiping out data" but I have never seen this. We make changes to tables all the time and the data stays in tact. Include schema changes in your deployments. If you are making changes directly to production you probably want to rethink.
Originally posted by Jeremy Brayton
Personally I would never use a staging or testing database as it adds a layer of complexity I don’t need. |
|
This means you are testing your deployment on production. This is contrary to the advice we give all of our customers.
Originally posted by Jeremy Brayton
When I think about all of this, the implementation is really going to center around what you can do. Does each dev have the sales client on their machine? |
|
Yes, a multi developer environment definitely throws a monkey wrench in the works. Unfortunately SalesLogix is not friendly in this manner. Your developers just need to coordinate.
In general, this is our development cycle:
1. Make development changes (including schema) to the dev environment
2. Unit test the code on development
3. Build deployments (including schema, KnowledgeSync packages, .Net installs, etc)
4. Deploy to the staging environment (this must mirror production - may require a refresh if a previous deployment failed)
5. perform QA, UAT, whatever you call it
6. repeat steps 1-5 until QA passes
7. Once passed, deploy to production
I hope this helps.
Timmus |
|
|
|
Re: Server Setups
Posted: 19 Apr 06 3:58 PM
|
fiogf49gjkf0d We run 4 machines, each of them boots from and stores data on seperate SANs.
1 for production SLX/sync server
1 for production database server
1 for test SLX/sync server
1 for test dabase server
We refresh the dev database on an as needed basis. |
|
|
|
Re: Server Setups
Posted: 20 Apr 06 9:06 AM
|
fiogf49gjkf0d Argh Timmus, I know no quoting so I'll have to do my best.
Staging DB:
I see the error of my ways. As a lone developer I don't have the luxury of someone "signing off" on something. They do this when it's released to their computer in production and I'm VERY FORTUNATE not to have deployment issues. I've had very minor ones that I've been able to correct thankfully but it is like playing with dynamite before using it.
Copy of production DB:
I did this initially WAY back during our 6.1 upgrade. I literally converted EVERY customization to VBScript and there was no way I was creating everything from scratch. Once I got the customizations to where I thought they should be, I bundled them and moved them to a fresh blank copy and installed the bundles to it. In essense, it was a very limited staging database at this point, that has morphed back into a development db.
The reason I keep this data separate is that during our upgrade from 5.2 to 6.1, some float data was corrupting the results. The plugin would work fine when you create new data but the old float had something like 6.2999999999999 and whenever you changed this erroneous field, the ENTIRE dataset wouldn't update. I solved the problem by a Clone() function I had developed for renewal purposes that created the correct float from the old one (don't ask me how it magically worked but it did). I may be a little anal for doing things this way but I build customizations that should work on any database and generally I've been fortunate enough that data really isn't a problem.
Bundle table definitions:
I always update bundles that are currently installed. These bundles already have their table definition in the database. Previous versions if you accidentally chose to install those tables again, it would wipe the data but update the schema. Does it magically know that if a table exists with the same name to look for only those columns that have changed and insert those? I wish that were true and it's possible I'm operating from 5.2 land on this. I just remember making the mistake once and having to import records back in. That's why some bundles had FIELD (DATEWHATEVER) entries instead of just tables.
Dev cycle:
Ahh unit testing. I had to change a section of code that calls after a Word document is filled out. If I were smart, I would segregate all UI data from the core code and build a test bed to analyze the core separate from the production UI. This would mean I could test my Attachment.Insert() function without having to go through the entire CreateWordDocument() process. I have a lot of coupled code but a good bit I move to what I call base classes when I see I'm copy/pasting code. I do like the idea of keeping 1 script per 1 form but modularity would make testing this stuff a LOT easier than it is now.
My biggest problem is I don't have the budget for a development sync server to test how synchronization is handled. I've been lucky enough not to run into too many problems because of it but it requires at least a server and a remote client. I could use 2 virtual machines and swap back and forth but I probably wouldn't quite have enough RAM on the laptop to handle them both at once. It's worth trying at least so perhaps a staging db would kill 2 birds with one stone. |
|
|
|
Re: Server Setups
Posted: 21 Apr 06 6:15 AM
|
fiogf49gjkf0d Well, we kind of keep it simple here. For production e have the Sync, SpeedSearch and SLX server on one box. The DB is on another.
We have two development versions of the DB. One dev DB sits on the same box as the production. This is used mainly for test scenarios, building contact processes, etc. It most closely resembles the production version and is refreshed more frequently and carefree than the 2nd development DB. Its more of a staging area.
The 2nd development DB sit on a totally different server. This is used to create custom scripts, forms, etc. It is also the first SLX that gets any upgrades applied to it before going to production.
John G. |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|