We have a small team currently working on numerous projects. We originally started out as a two person team and jumped in head first without any kind of source control. We currently break numerous best practices and do development on live sites (yuck, I know).

We're in the process of fixing this issue incrementally. The first step, which we're in the midst of implementing, is separate development and production instances of sites and internal processes for pushing code from dev to prod and how to handle situations that require rolling back those changes. This still leaves us with the issue of more than one developer working on the same file and overwriting each other.

The next step, and this is where my question comes in, is implementing a much larger, sweeping change, and implementing source control. Obviously, source control works best when each developer has their own local repository. My searches have yielded mostly scenarios that involve a remote SCM server and each developer pulls down a copy to their local machine for development. For a myriad of reasons, which I won't get into here, development on local machines won't work for us, so, please don't respond with questions about why we don't just do development on local machines.

So, what I'm envisioning is a remote development server that can serve multiple functions. First, it can act as the staging server for our projects. Second, it can act as the development server for all our developers. Their IDE, obviously, would still be on their local machine and they'd connect to the remote development server as they've always done. The rub is integrating source control into the mix.

Let me throw out the disclaimer that I know enough about source control to be dangerous, but not enough to actually implement anything.

With that said, here are my thoughts.

1) The application server supports instances, so staging and each developer would have their own instance.

2) Staging and each developer would have their own root folder on the server and sites within each root folder would be accessible via subdomain, like so:

D:/Dean/...
    .../Inetpub/wwwroot/example1.com/wwwroot/     --->  dean.example1.com
    .../Inetpub/wwwroot/example2.com/wwwroot/     --->  dean.example2.com
    .../Inetpub/wwwroot/gaggle.com/wwwroot/       --->  dean.gaggle.com
    .../Inetpub/wwwroot/yoohoo.com/wwwroot/       --->  dean.yoohoo.com
    .../Inetpub/wwwroot/bong.com/wwwroot/         --->  dean.bong.com

D:/Sue/...
   .../Inetpub/wwwroot/example1.com/wwwroot/      --->  sue.example1.com
   .../Inetpub/wwwroot/example2.com/wwwroot/      --->  sue.example2.com
   .../Inetpub/wwwroot/gaggle.com/wwwroot/        --->  sue.gaggle.com
   .../Inetpub/wwwroot/yoohoo.com/wwwroot/        --->  sue.yoohoo.com
   .../Inetpub/wwwroot/bong.com/wwwroot/          --->  sue.bong.com

D:/Jorge/...
     .../Inetpub/wwwroot/example1.com/wwwroot/    --->  jorge.example1.com
     .../Inetpub/wwwroot/example2.com/wwwroot/    --->  jorge.example2.com
     .../Inetpub/wwwroot/gaggle.com/wwwroot/      --->  jorge.gaggle.com
     .../Inetpub/wwwroot/yoohoo.com/wwwroot/      --->  jorge.yoohoo.com
     .../Inetpub/wwwroot/bong.com/wwwroot/        --->  jorge.bong.com

D:/Li/...
  .../Inetpub/wwwroot/example1.com/wwwroot/       --->  li.example1.com
  .../Inetpub/wwwroot/example2.com/wwwroot/       --->  li.example2.com
  .../Inetpub/wwwroot/gaggle.com/wwwroot/         --->  li.gaggle.com
  .../Inetpub/wwwroot/yoohoo.com/wwwroot/         --->  li.yoohoo.com
  .../Inetpub/wwwroot/bong.com/wwwroot/           --->  li.bong.com

D:/Staging/...
       .../Inetpub/wwwroot/example1.com/wwwroot/  --->  staging.example1.com
       .../Inetpub/wwwroot/example2.com/wwwroot/  --->  staging.example2.com
       .../Inetpub/wwwroot/gaggle.com/wwwroot/    --->  staging.gaggle.com
       .../Inetpub/wwwroot/yoohoo.com/wwwroot/    --->  staging.yoohoo.com
       .../Inetpub/wwwroot/bong.com/wwwroot/      --->  staging.bong.com

Each of these root folders would contain all resources necessary to make these sites function -- code libraries, user-defined function files, custom tags, components, third-party assets like Bootstrap, Font Awesome, etc.

Additionally, each of these root folders will act as the home for all "local repositories" for each developer and the staging root folder will act as the home for finalized code for QA before deployment to production.

3) A single instance of IIS would support all of this. As developers are tasked with writing web code and not with managing any aspect of IIS, how requests are parsed prior to handing it to the application server for their code to process, etc., I don't see any issue with IIS being a single instance (in fact, it makes it easier to enforce similarity of environment).

4) I haven't settled on a source control solution yet. I'm leaning toward some manner of DVCS like Git or Mercurial.

5) It appears that separating the repository from the IDE so they're on separate machines is somewhat problematic. As seamless integration with source control within the IDE is the surest way to gain adoption, I'd love to be shown my understanding is incorrect.

So, after all this, my question is...

How can we have source control and have developers working on a remote development server and have it seamlessly integrated into their IDE?

Also, a helpful (or annoying, depending on your perspective) caveat is we're a ColdFusion house and use ColdFusion Builder 2016 (which is Eclipse, under the hood) so whatever solution there is would need to work with that. We're also running Windows Servers and a mix of Windows and Mac local machines, if that affects the solution you'll suggest.

  • 1
    You could do this yourself with Git and a Windows Server, with people remoting in and having the appropriate permissions only on their shares, but I guess the bigger question is why? If the developers have local machines, they can develop on them. If you don't trust them, then there's no point in giving them any code. programmers.stackexchange.com/questions/10736/… – mgw854 Oct 20 '16 at 0:16
  • I'm not interested in discussing why we're going this route, why doing development locally doesn't work for us, etc. I'm interested in how to make this particular approach work. – OregonJeff Oct 20 '16 at 0:23
  • 1
    "development on local machines won't work for us" - delirium and stupidity and lack of understanding... technically anybody anytime can write code into local file in local IDE. Deploy (more or less smart) in another question and separate task – Lazy Badger Oct 20 '16 at 1:10
  • 1
    @OregonJeff: What does the workflow currently look like for a developer when he wants to make a change that is only visible in his own development environment (for example, to test something that isn't ready to be shared with others). – Bart van Ingen Schenau Oct 20 '16 at 11:12
  • 1
    It's critical to understand the constraints of a problem. After some Googling, it appears that you're using ColdFusion's RDS Fileview to access files. If you'd mentioned that in your original post, rather than a generic "this is what we want to do" it probably would have gotten better answers. And, to be honest, I think that as a specific question, it's more appropriate for SO rather than this site. – kdgregory Oct 21 '16 at 13:13
up vote 2 down vote accepted

Windows Server is perfectly capable of handling something like this with some manual intervention (or better yet, PowerShell scripts). I'd suggest using Git, because I know it can handle the situation you're dealing with (and it's generally well regarded for handling multiple users). Move all of your source code into Git, which you can host on your server. I'd lock down everything related to the master branch once you set it up so that it can only be merged into by a build/deployment tool.

Here's the steps I'd follow:

  • Create user accounts for each user on the server
  • Create a directory for each user, provisioned with the correct permissions
  • Clone the repository into each of the new directories
  • Create an app pool per user in IIS
  • Create all the applications per user in IIS and assign them to the app pool
  • Share the user's directory as a network share
  • On the local machine running the IDE, use the network share path as the project folder

This should get you everything you want. As a network share, the developer can interact with it as if it is local. The one caveat I've noticed is that network shares don't always trigger the same file change events as local folders, which can make certain hot reloading tools not work.

  • Is the network share necessary for the local Git client to work on their machine against their remote "local" repository on the dev server? If not, I'm worried that network shares are notoriously unreliable and often have fairly serious lag issues. – OregonJeff Oct 20 '16 at 0:50
  • They certainly can be problematic, but distributed source control is meant to run on local machines. If the source is elsewhere, you still need to expose those files locally somehow. A network share is the only way to do that seamlessly. – mgw854 Oct 20 '16 at 0:53
  • I wonder if a product like WebDrive which makes it possible for FTP connections to function as a mapped drive would make this more seamless. Any thoughts on that approach? – OregonJeff Oct 20 '16 at 1:02
  • 1
    Everything you do is going to be inherently unreliable because you're using some sort of network. FTP isn't really more reliable than CIFS. I'd also caution you against trying to tack on solutions to this problem; I'd again humbly submit that the problem you're dealing with isn't the one you're trying to solve. – mgw854 Oct 20 '16 at 1:09
  • What is the problem I'm dealing with then? – OregonJeff Oct 20 '16 at 1:21

Short answer

Easy. Any Windows network-share, announced in LAN, can be mounted as additional local drive on any host in LAN and resources on this share will be presented as local to local OS. Just do it

Longer answer

Microsoft SMB Protocol is still the poorest and worst choice over alternatives - especially for case more complex, than just "share text/plain files". If you can, it will be better to invest some time, attention, money into investigation and deploy SMB-alternatives (point one, point two) from the very beginning, than have disasters, interrupting business

PS: from my POV, local repos with remote bare-repo still is the most reasonable and natural way with no headache and transparent workflow without carefully scattered garden rakes in the grass

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.