I've played with the in DW/Vault integration for a few minutes, and have been trying to decide that best way to the new feature. Note: I don't have any experience with source control/IDE integration. Unlike many vault users, up to this point everyone in our company has only used the Vault GUI client.
Our current environment:
- we have a few employees that use DW to manage our website
- a Vault server that has the current website $/Website
- a Win2003 Server that contains the company website
The first problem I ran into with the new DW/Vault integration was the setup process used the Site Name from my DW application to create a new folder in Vault. I have no idea what other users have named their dw site definition, but I doubt we all use the same name. I'd like to be able to force my DW Site Definition to use our existing vault structure: $/Website
The next hurdle would be how to get modified pages to the Win2003 server on a checkin? I'd guess that the best way would be to create a shadow folder using the win2003 UNC name... However, we tried UNC shadow folder links back when the feature came out in vault 2.0... I think we got it to work after using impersonation and playing with permissions, but then dumped it for performance reasons. Any thoughts on using shadow folders or have any other ideas?
I know this is just a preview, and I sure like what I see...
Thanks,
Don
Trying to figure out how to best use DW/Vault Integration
Moderator: SourceGear
-
Don Thimsen
- Posts: 114
- Joined: Fri Mar 05, 2004 11:18 am
- Location: Raleigh, NC
Re: Trying to figure out how to best use DW/Vault Integratio
I believe you can remove the site name in the Vault dialog that sets the working folder, and this won't create a subfolder. So, essentially, you can name the top level working folder to be what you want, as long as all the subfolders are the same name.Don Thimsen wrote: The first problem I ran into with the new DW/Vault integration was the setup process used the Site Name from my DW application to create a new folder in Vault. I have no idea what other users have named their dw site definition, but I doubt we all use the same name. I'd like to be able to force my DW Site Definition to use our existing vault structure: $/Website
We wouldn't recommend Shadow Folders for web site deployment, since Shadow Folders is implemented as a low priority update thread (and can lag checkin time by a few minutes, sometimes longer under heavy load), and also, just in terms of process, you probably want an extra step to verify that what was checked in is actually a change you want propagated to the website.The next hurdle would be how to get modified pages to the Win2003 server on a checkin? I'd guess that the best way would be to create a shadow folder using the win2003 UNC name... However, we tried UNC shadow folder links back when the feature came out in vault 2.0... I think we got it to work after using impersonation and playing with permissions, but then dumped it for performance reasons. Any thoughts on using shadow folders or have any other ideas?
We are still new to Dreamweaver, but would the Testing Server work as a way to deploy? If DW doesn't have a Deploy facility, the best way to do it in Vault is to simply invoke Get Latest when you are ready to update the website.
-
Guest
Testing server should work perfectly for deployment. The upload feature (ctrl-shift-u) should upload to the testing server and the check in/check out should deploy to the Vault.
We have local folders declared for "working folder"s for Vault and then you set your Test Server location where you want the files to be uploaded for actual testing. Or if you're an authorized uploader for live, then point it to the live server.
The reason for the local folders is so that you are only testing YOUR changes and not having to see other peoples changes on your own local copy of the site. That way you can run/look at the site at localhost w/o affecting anyone elses changes. This is essential for any kind of .NET or server side environment coding.
We have local folders declared for "working folder"s for Vault and then you set your Test Server location where you want the files to be uploaded for actual testing. Or if you're an authorized uploader for live, then point it to the live server.
The reason for the local folders is so that you are only testing YOUR changes and not having to see other peoples changes on your own local copy of the site. That way you can run/look at the site at localhost w/o affecting anyone elses changes. This is essential for any kind of .NET or server side environment coding.
-
Don Thimsen
- Posts: 114
- Joined: Fri Mar 05, 2004 11:18 am
- Location: Raleigh, NC
I don't understand... The first paragraph states:
>>Testing server should work perfectly for deployment.<<
But , the rest of the post talks about testing without affecting others...
If I use the testing server as a way to deploy (ie. test server points to our production website), isn't that going to be updating our producton website as I'm testing pages. Note: I don't currently use a testing server, so I may have a misconception as to what the server is for, and how it works.
From my perspective, when I check something back into vault, I'm going to be committing the change to the production website as well - whether it's part of the checkin process using shadow folders, or some manual method.
Don
>>Testing server should work perfectly for deployment.<<
But , the rest of the post talks about testing without affecting others...
If I use the testing server as a way to deploy (ie. test server points to our production website), isn't that going to be updating our producton website as I'm testing pages. Note: I don't currently use a testing server, so I may have a misconception as to what the server is for, and how it works.
From my perspective, when I check something back into vault, I'm going to be committing the change to the production website as well - whether it's part of the checkin process using shadow folders, or some manual method.
Don
-
Guest
In dreamweaver you should have 3 locations for your site under the site setup:
Local Info
Remote Info
Testing Server
The local info is where it should point to on your local computer. In my projects I set these up on my D: drive under the websites folder which ends up looking something like this:
D:\Websites\CompanyA
D:\Websites\CompanyB
Each of those folders contains the actual site files be they php, aspx, html, etc. I also point IIS to each of these folders so that when I go to test each site on my local computer I don't need to upload to an active webserver to test my code. I could also in effect modify my hosts file to point the correct domain name to 127.0.0.0 or my localhost in order to test with the actual domain name present.
The remote info is where you set up your vault server. This holds all your vault files and serves as your source control (not an active website folder, nor on a website server, or at least I would hope it's not)
The testing server can be pointed to where ever you would like to deploy your website. So in the event that you are a developer and are not authorized to push to a live webserver, but are authorized to push to a development webserver, you would set this up to point to that development webserver. If you were a manager and had authority to push updates, then you would point this to the live server.
Does that make more sense?
Local Info
Remote Info
Testing Server
The local info is where it should point to on your local computer. In my projects I set these up on my D: drive under the websites folder which ends up looking something like this:
D:\Websites\CompanyA
D:\Websites\CompanyB
Each of those folders contains the actual site files be they php, aspx, html, etc. I also point IIS to each of these folders so that when I go to test each site on my local computer I don't need to upload to an active webserver to test my code. I could also in effect modify my hosts file to point the correct domain name to 127.0.0.0 or my localhost in order to test with the actual domain name present.
The remote info is where you set up your vault server. This holds all your vault files and serves as your source control (not an active website folder, nor on a website server, or at least I would hope it's not)
The testing server can be pointed to where ever you would like to deploy your website. So in the event that you are a developer and are not authorized to push to a live webserver, but are authorized to push to a development webserver, you would set this up to point to that development webserver. If you were a manager and had authority to push updates, then you would point this to the live server.
Does that make more sense?
-
Guest
Also, checking in the file and deploying to a live server or web server to me would seem like a bad idea. If any of your project needed the ability to change permissions on a file (say to write to an XML file or a binary file), they would be fighting for those priveledges with the source control server. Something that could lead to a bunch of headaches.
Also source control is usually used for development. What is checked in needs to usually be QA'd before it's sent live, thus conotating source control not being on a webserver or pointing to a webserver folder. I know it adds an extra step in the process, but in a huge dev environment, that's key to having a working production team. Also if source control goes down, or is on the fritz, or likewise your webserver goes down, you would still want to be able to develop.
I'm not saying it's wrong or right, just proposing some situations that might issue the need to set it up differently. If what you have works for you then don't change it up just to try something new, I'm just communicating my experiences with web development and source control and what we've come to use as a process and why.
Also source control is usually used for development. What is checked in needs to usually be QA'd before it's sent live, thus conotating source control not being on a webserver or pointing to a webserver folder. I know it adds an extra step in the process, but in a huge dev environment, that's key to having a working production team. Also if source control goes down, or is on the fritz, or likewise your webserver goes down, you would still want to be able to develop.
I'm not saying it's wrong or right, just proposing some situations that might issue the need to set it up differently. If what you have works for you then don't change it up just to try something new, I'm just communicating my experiences with web development and source control and what we've come to use as a process and why.
-
Don Thimsen
- Posts: 114
- Joined: Fri Mar 05, 2004 11:18 am
- Location: Raleigh, NC
It's the Testing Server being tied to our production website that's bothering me... From what I've read about testing servers, I thought they were used for dynamic webpages that needed server side components to handle dynamic content. It seems that you want to use testing server as a production deployment system.
The reason we've never looked at a testing server was that none are needed for our site. We currently have about 100 .htm pages for basic content (vault controlled), and about 2500 generated pages that are dynamically tied to MS Exchange ( these are outside of vault control). We also have a total of three .asp pages, and those can be tested on local IIS running on XP Pro.
Lets assume I point Testing Server to our production server, and I have the Remote Server setup for vault. I thought cntl+shift+u would put the file back to the remote server. If I understand what you've said about testing servers, the PUT would now target the testing server.
I think I'll take some time tonight to play with all this, and read more about testing servers and dreamweaver source control.
Thanks,
Don
PS. I think I'm also getting confused by the DW doc, because "Enable check in and check out" on the Remote Server definition in the documentation seems to mean something else entirely... So, I'm running into help documentation about checkin/checkout that is not related to a source control system.
The reason we've never looked at a testing server was that none are needed for our site. We currently have about 100 .htm pages for basic content (vault controlled), and about 2500 generated pages that are dynamically tied to MS Exchange ( these are outside of vault control). We also have a total of three .asp pages, and those can be tested on local IIS running on XP Pro.
Lets assume I point Testing Server to our production server, and I have the Remote Server setup for vault. I thought cntl+shift+u would put the file back to the remote server. If I understand what you've said about testing servers, the PUT would now target the testing server.
I think I'll take some time tonight to play with all this, and read more about testing servers and dreamweaver source control.
Thanks,
Don
PS. I think I'm also getting confused by the DW doc, because "Enable check in and check out" on the Remote Server definition in the documentation seems to mean something else entirely... So, I'm running into help documentation about checkin/checkout that is not related to a source control system.
-
Guest
Looks like I inherently remembered this experience incorrectly (see other thread).
I would love to have it operate the way I described, but you are correct that ctrl-shift-u uploads to vault at the moment. Which is kind of disappointing, because that means I'll need to find some other method of site deployment, or figure out a way to get get/put to do what I want them to do. (which is essentially publish)
You are correct that testing servers are for "testing" but it's also just another server, so you could essentially still hook it up to your production server and go into the expanded view (where it puts local on one side of the screen and testing/remote/whatever on the the other side). Then when you do put/get it will actually send/receive from the appropriate server. Which is what I'm doing now on our SCC projects.
If you don't use the setup I defined, I'm sure you'll find your own ways of utilizing the other server settings to your advantage. Again, if you're a small shop, use whatever works for you, no use switching if you can get your projects out just as fast with a way that makes sense to you.
I would love to have it operate the way I described, but you are correct that ctrl-shift-u uploads to vault at the moment. Which is kind of disappointing, because that means I'll need to find some other method of site deployment, or figure out a way to get get/put to do what I want them to do. (which is essentially publish)
You are correct that testing servers are for "testing" but it's also just another server, so you could essentially still hook it up to your production server and go into the expanded view (where it puts local on one side of the screen and testing/remote/whatever on the the other side). Then when you do put/get it will actually send/receive from the appropriate server. Which is what I'm doing now on our SCC projects.
If you don't use the setup I defined, I'm sure you'll find your own ways of utilizing the other server settings to your advantage. Again, if you're a small shop, use whatever works for you, no use switching if you can get your projects out just as fast with a way that makes sense to you.