March 17th, 2011, 03:16 PM
Need Developer Tools Help!!!
Ok, take for instance the following scenario (setup). There are roughly 4 developers all working to maintain the same set of 30+ different websites on a company intranet. Therefore, none of us want copies of files locally on our individual machines because that would essentially be 4 copies of every site per machine (overwhelming and confusing). We have a remote server set up as a development server with ColdFusion 9 installed. We do all our development work directly ON this server and test via browsers to this server. Once finished, we publish files over to our production server(s). We do zero code editing directly on the production server(s).
Now, we used to use FrontPage for development work because we all could connect (HTTP) to the development server and work with the same set of files. FrontPage only had one option of version control and that was to warn you if someone else had previously saved a different copy of the file you had open. FrontPage was also great for us in that all we had to do was publish the site or individual files as needed to whatever server we typed in (as we have several to publish to at times).
We since are trying to migrate away from FrontPage and get into a better development tool. However, we have yet to find one that best fits our setup. We find ourselves using DreamWeaver to edit code, and FrontPage to publish, etc. Also, within DreamWeaver, we do NOT want local copies of the files saved on our machines so setting up DreamWeaver is tricky since they require local AND remote setup. In our case, they are both the same and did not always work (if ever) for file check in/out because of this.
I have done some research on the tools available but was wondering if anyone else has a similar setup. If so, or if anyone has any ideas, can you suggest a development tool that would best fit our needs so we can all work within the same websites at the same time without causing problems and without having copies on our local personal machines.
I think the biggest problem that we run into is that we do not have a development server and a testing server. We use the same server for both roles before pushing to production servers.
Thanks in advance to whomever suggests solutions.
March 17th, 2011, 03:55 PM
Having everyone develop on the same server is going to be, at best, problematic, and at worst, a nightmare. Don't do this.
Set up a Subversion or Git repository and check in the code to the repository. Each developer will check out the projects that they need to work on, do the work and test locally, then commit the updates back to the repository. When a release is ready, you create a tag in the repository (1.0, 1.1, etc.), and then you push that set of code to the testing server. When the testing is done, you then push the code to the production server.
This is how virtually all professional development work is done nowadays. Anyone not using version control at this point is making their lives harder for no reason. For a lot of great information on this topic, I recommend "Pragmatic Version Control with Subversion" and/or "Pragmatic Version Control with Git".
March 18th, 2011, 08:37 AM
Thank you for your reply!
We have had these servers set up this way for years because when using FrontPage everything worked rather well. Now that we are getting way more advance with ColdFusion coding we were looking for a nicer tool to help with context editing.
With the suggestion you made, how much "change" will we need to go through in order to have this new setup? We do not exactly have that much free time to manipulate the way our info is set up. Sadly
March 18th, 2011, 09:36 AM
The answer really depends on your familiarity with version control and setting up a local environment.
Installing SVN or Git on a central server takes about 30 minutes if you know what you're doing, but might take a day if you don't.
Installing CF, Apache/IIS, and a database server on the developer machines takes about an hour if you know what your doing, but might take a day if you don't. One way to make that easier is to use something like VMWare Workstation, create a virtual machine image with a barebones OS install with CF, web server, and database set up, and then simply give the image to your developers to use. Then they can be up and running in 5 minutes.
Using Git or SVN will involve a learning curve for the team if they have not used version control before. So again, I would strongly recommend the books I mentioned earlier.
You say you don't have a lot of time for this, but where will you find the time when the developers accidentally delete or overwrite each other's changes because they're all developing concurrently on the same machine?
March 18th, 2011, 12:37 PM
I see what you are saying about overwriting and such, but like I mentioned earlier.. This is why we were using FrontPage and then Dreamweaver for developing. FrontPage would warn you before you overwrote files, and Dreamweaver will not let you open the same file at the same time with check in/out. However, both of these have their separate issues with how we are set up and thus prompted this question here.
The main thing we were trying to avoid was having copies of all of our websites on each of our machines as "local" versions.
It's also hard to explain the finer details of our setup currently but looking for a place to start initially for some ideas.
March 18th, 2011, 01:00 PM
Locking files is a poor solution, because it is totally possible that more than one person needs to work on something that the same time. Particularly if the architecture includes common, reusable code that is used by all of the applications. Version control eliminates this because if two people edit the same file, the VC system will merge the changes. And if two people edit the same line of code in the same file, the developer will be told about the conflict and given the opportunity to determine how the merge happens.
But that's only one of the many reasons that everyone should always use version control. Much more critical is the ability to maintain a continuous record of every change made. This allows tagging, which I mentioned earlier, but also makes it easy to roll back a change or set of changes if something goes wrong. Without VC this causes potentially disastrous problems.
Further, developers can easily branch an existing part of the repository, work on it and commit their changes as they go, and then when they are done, merge their branch back into the main code base.
There are many more benefits to using VC that I won't elaborate on, but which are described in minute detail in the books I mentioned. There really is no excuse not to be using version control. Ever.
Regarding local files, the developers don't have to have local copies of the entire repository. They can check out only the parts that they need to work on, and then delete the local versions when they are done if they want to. That's because the VC system is the master source for all of the files.
But beyond that, what exactly is the issue even if they DO check everything out? Even an absolutely gigantic code base of 10 Gb is nothing when a 1 terrabyte hard drive is $100. So the reason can't be disk space. What's the problem?
March 18th, 2011, 02:06 PM
You would think that would not be an issue. However, that is the main problem here. The company is very picky on what they allow us to purchase. Granted we COULD buy them ourselves but I refuse to use my own pocket to benefit the company. If it's for work use, work should pay for it in my eyes. They always tell us "you don't need that" and we never buy much. It's an ongoing battle so like I've mentioned before, just looking to see if there are any solutions that mimic what we already have set up. If not, we'll have to try and convince them this is a better idea and work towards building this.
March 18th, 2011, 02:41 PM
I guess I have a hard time believing that the disk space on the developer machines is the limitation. How big is the source code? 50 Mb? 200 Mb? Even 200 Mb would be a huge amount of code. If the developers don't have room to store the code on their machines then yes, something is very wrong.
The list of cons to NOT using version control is so long, and the list of pros to using it is so long, that this should be a no-brainer to anyone. You can also try pointing out that virtually all, I mean ALL, professional development teams use version control. This isn't something that is debated any longer. In fact, it hasn't been debated for a decade. This is an industry-wide standard, and it is simply the way everyone works.
The cost of adopting it is trivial compared to the cost of not adopting it. If someone wastes just a few hours of billable time because they lost their code, overwrote someone's changes, or have to manually revert changes they've made, that's already more than the "cost" of adopting version control. SVN and Git are both free.