I have been running a poll on my site for a couple of months now, asking users how they develop their applications (on a live production server, on a shared development server, developers running the free developer edition locally, or on a separate development instance on a production server). With over 600 responses, here are the findings. The bad news is that too many of you do your development on live server, while that is terrifying to say the least, thankfully it is only 14% of respondents. The good news is that 52% of you use a dedicated development server or a dedicated development instance on a shared server, that is good to hear. The somewhat surprising result is that just 32% of you use the free Developer Edition, preferring to development on shared servers instead. And so my question to you is why? Please share.
Why Aren't You Using the Developer Edition?
21 responses to “Why Aren't You Using the Developer Edition?”
-
I did a talk at MXDU on "Taming the Code" — the audience split was similar when I asked the question on where people develop. I think it boils down to this.. to effectively develop in a decentralised environment (ie on Developer Edition CF) you need to have version control in place. And the majority of CF development houses do not see the ROI for implementing formalised code management — simple as that.
-
We used a shared server up until about 6 months ago. At that time we switched to each having their own developer edition copy. The switch also required we move to CVS at the same time and upgrade two developer’s PCs. It was well worth it and we’re really happy with the move.
-
Ben,
Your poll only allows you to answer one way. In our shop we use a combination of both a shared dev server and the developer edition. Each developer has a local copy of the developer edition on their laptop. They then can work from home or on the train or whatever. Then they check the code in and it is unit tested on the shared development server.
Barry -
Others have explained their situation to me like this. They don’t have code management in place in the traditional since. However it is not because people don’t see the ROI, the problem is spending the investment up front that they can’t afford, even if there is going to be a return in the long run.
-
Ben, I don’t use the developer edition, because we only have a licensed CFMX Professional. The free developer edition only acts as a CFMX enterprise edition. As a consequence, it’s possible to accidentally develop code that will not work on the live server because of licensing issues
-
Jille, the differences between Standard and Enterprise are primarily performance and administration related. The exception being some of the Java integration. But core CFML is the same. Is that what you are referring to?
-
We use a shared development server because we don’t want to license all the 3rd party products for every developer (so we have 2 copies, one production and one development), and most of the developers aren’t talented enough to manage a server themselves. I certainly don’t want to be responsible for installing the developer version and PWS and our 3rd party products on all of their machines.
-
Ben,
I am indeed referring to the Java and jsp integration part. Our applications use Java, integrate tightly with servlets or other java applications. Unfortunately, my boss didn’t want to purchase the enterprise edition, so we have to be very carefull with java integration and licensing 🙁 -
At our organization we develop on a shared development platform mirroring our production environment. This can be a pain because we have to consider who may be working on what, even with Source Safe being used. We’d use developer editions on our local machines but the production server is a Solaris box.
-
I’ll echo the others… Every shop where I’ve worked does a combo of shared dev server as well as a developer copy on each workstation. Allows each developer to work disconnected (ie. on the train) and more importantly, allows them to experiment freely.
-
We have a dev server & Production server. We only work on production server when there is an obvious non-evasive bug fix. All work is done on the development using DW for check in / check out. we don’t use the developer edition because it only allows for 2 IPs (127.0.0.0 & one other) and our team is a larger than this. We also get some customer who play in our development environment, and try to break things etc. The dev server really helps out for this portion because it allows us to do a lot more testing and playing around before dumping to production.
-
I’ll agree with Geoff and others that distributed development – using Developer Edition on every engineers desktop – requires source code control to be in place and a large number of CF shops don’t seem to use source code control.
That makes it quite a big jump to go from shared development to distributed development (with source code control).
For reference, the macromedia.com Web Team use distributed development – Developer Edition on every Mac/Windows desktop for engineers – with CVS source code control. We have automated builds to three shared development servers (different branches) for unit testing and validating spot fixes. We also have automated builds to three QA servers (again, different branches) for ongoing testing by the QA team. Then we have automated builds to an integration test environment for load testing and pre-production acceptance testing. Finally we do automated builds to production. All automated builds are driven from the CVS system. -
Due to local security policy, we are not authorized to run any type of non-standard services on our workstations. We will be changing to a shared development environment. Additionally, including myself, there are only two developers and the other developer refuses to change his ways of doing things. Please don’t suggest talking to management as they’re clueless about technology.
-
Same as some others mention here, independent developer servers on XP pro laptops using PWS. shared "stage" server for testing. VSS for source management. Would love to hear from anyone who is spicing up this mix with Virtual PC.
-
it’s because IT Departments (and Bosses) don’t trust anything that’s free
-
From my experience, I have to agree with those who identify lack of version control as the main reason people don’t do local development. In the last couple years I’ve helped a number of clients move to using CVS, and it has changed their lives for the better.
I must say I am surprised to hear people on this thread say that the ROI is not there, or that the initial investment is too hard to justify given the great open source options for version control — CVS being the most obvious, with the newer Subversion package coming on strong. It takes less than a day to set up AND learn how to use CVS, and with modern GUIs like TortoiseCVS (not to mention CVS plugins for Dreamweaver, Eclipse, and other popular IDEs), it’s extremely easy to use. If you aren’t using version control, you should be — and it’s easier than you think. -
Just some reasons for shared server development (proven effective with team of 12):
oAutomated nightly backups of all latest development code combined with source control nearly eliminates loss
ooEveryone has access to latest code at all times
ooNo code synchronization downtime
oInexpensive lightweight developer workstations
ooFast boot times and maximum resource availability for client applications
oExtreme-Programming-like development but with developers on separate machines
oEasy to maintain, centralized configuration of web, application, database servers as well as web services (local and remote), network file shares, CORBA services, software API’s
ooDevelopers focus on developing without configuration distractions -
Certainly the overhead for system engineers, as mentioned by the others here is the most important reason. But one irreplaceable benefit of using the centralized server for test is with coding. At my old company, every time someone designed a cfquery poorly, like –
SELECT * FROM mymegatable
– everyone else would find out, because they couldn’t do anything until someone restarted ColdFusion services. That set up a red flag so that the code could be analyzed before it got to the customer. -
I work at an Army base in suppose of the Army Budget Office. We are not allowed to install ANY type of server on our workstations due to potential security breeches. I’d prefer to develop on my workstation AND incorporate source control, but we can do neither (source control software is apparently another potential secruity breech) and thus we lose much productivity to developers constantly overwriting each others code.
-
I’m echoing what’s been said here a little, but essentially we’re working in a shared development environment on a remote server because our developers are running on both Macs and PC’s.
Our servers are UNIX/Apache or Tomcat which I don’t want to reproduce locally.
However, since I’m going to IIS and FTPing for our CF user group website, I do all my development for those pages using the developer version. I sure hope MM keeps providing it! -
We have shared dev, test and production environments (all Solaris, MX Ent. with sandboxing) and I use CVS for source control locally. However the Developer Edition is really useful for testing out a new Java class or some other strange thing without having to explain to the sys admins why you want to put an untested open-source Java class on a shared server…
Leave a Reply