On 9/14/05, Paul <[EMAIL PROTECTED]> wrote: > > > > I am the sole developer for a non-tech company. > > > > > > > Lots of us geeks are :) > > > > > Agreed :) > Funny, the discussions here made me think of everyone as part of some > well-oiled development machine in technical Utopia... Glad I'm not alone in > my "loneliness"!
Just b/c you're solo, doesn't mean that source control, build tools, and the rest of the development toolset are not for you. In some ways, it's far *easier* to implement them because the only management buyin you need is yourself! And quite honestly, it saves you time to implement at least the basics -- source control at least. It doesn't necessarily save LOTs time, but it moves the point you *invest* the time earlier in your process where it keeps everybody sane. Wow -- that's obtuse. Here's a true story: Company A has a rollout to do. I come in to help their sole developer (at a nontech company) package everything up for deployment. Turns out there were at least 5 seperate instances of the code -- his laptop, my laptop, two staging servers, and a production server. And he had 3-4 more copies laying around. So we ended up with an 8-way diff to sync up all the code. That's the couple days before the rollout -- everyone thought it was "tested", but no one was testing the same copy. So hours of testing wasted and about 10 hours of my time helping them out of the mess. Subversion takes about 30 minutes to install, especially if you're one of a) familiar with Apache b) happy to run the lightweight svnserve server c) able to access the files directly you can get away with (c) unless folks need external access to the repository. I'd also recommend the additional hour to read the first few chapters of Pragmatic Version Control with Subversion. So an hour of setup, an hour of reading, and a few hours over the next week to get comfortable with the process. And the time's invested upfront, so when things go to hell close to a milestone/deadline, you're not diffing 8 filesets, or digging through daily zip archives. Getting back to company A, we put in source control and made the developer use it. The next rollout was an emergency fix to handle a scaling problem that I had to work on from the opposite coast. I had actually fixed the bug in a larger project to rework the login process that was not yet complete, but could backport the changes since I could easily diff my branch against the main development and then deploy it for testing. The rollout took 5m the next morning with their graphic designer handline the svn commands for me while I rode the trolley into Portland... > > In SVN, you're looking at post-commit hooks to automatically push out > > changes, but I'd suggest looking at Ant -- which lets you create > > deployment scripts. And then you can take your working > > deploy-on-demand scripts and put it all into CruiseControl, which is > > an opensource tool for continuous integration builds (e.g. changes > > automatically roll out to the target server continuously). > > My brain actually started sweating. I guess I'll just take this one step at > a time... Great plan! Step 1: Source control Step 2: Automate deployments There is no step 3 :) -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218380 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
