My current project has a development web server and live web server. Developers make changes to files on the dev server and test them (by going to the dev address) and make changes as necessary. When the file or files are ready to go, they are copied to the live server. There is no version control.
As you might expect, there are some problems with this model:
It's hard to keep track of what other programmers have done.
It's hard to keep track of what files should be copied to the live server.
There is no version control.
I'm in a position to make nearly any change I like, but I want it to be the right one! I have been turning this over in my head for quite a while, and I have a solution that might be okay. But I want SO's opinion.
Certainly version control needs to be added. But how should it work with the existing codebase and where should the developers be testing? How can anyone know what needs to be moved to the live server? What other details need to be addressed?
How would you attack this problem?
Supplementary information:
The website is vital, but not mission critical. A small amount of downtime is acceptable.
There are very few developers. (Right now, only 4.)
History: Before I started, the project used Visual Source Safe. This was a sufficiently bad experience that they quit using it and abandoned version control.
The project is an ASP.NET (C#) website.
This seems like a question that may have a complicated answer. Thanks for thinking about it!
Use source control. Even VSS is better than nothing, but there are plenty of better alternatives, free or otherwise. Simple enough option in Subversion, with a plugin like VisualSVN to integrate with Visual Studio.
Developers' initial testing should just use their own local development web servers that VS will fire up, or their own local IIS instances.
Add a web deployment project to pre-compile the website, and exclude it from the debug build configuration so it doesn't slow everyone down when they build.
When you want to deploy, deploy the entire output of the web deployment project built in release mode. Don't do it piecemeal, otherwise you'll never know what's there.
Related
We're planning to select DNN+2sxc for a project for our team.
Normally when it comes to a CMS, I usually fly solo, but in a corporate .Net or Java environment it’s team collaboration, source control, Azure, deployments etc.
With our upcoming project we’re taking one of our main sites (C#/asp.net/razor) and converting it to DNN.
However, I’m currently unsure as to how to approach a CMS in a team development environment?
So in the development phase, we'll have some guys doing styling, others creating 2sxc reusable content templates and others building the actual pages. All at the same time, on the same website. In terms of Git/Visual Studio I'm not sure how it will actually work with relation to the DB especially. This question obviously applies to all CMSes (not just DNN) in a shared development environment.
What is the best practice to do this?
So I prefer to do most development locally, in my own instance (local IIS and local DB), with each individual project (module,theme/skin) in a separate repository. This makes the risk of me breaking someone else, or someone else causing me pain, minimal.
You can use a tool like Polydeploy to automate the deployment from the repository check ins into that upper environment. Requiring that individuals check code into the repository when ready to deploy to a test/uat/prod type environment.
Where it gets tricky is content for sure, I would typically do that in a test/uat environment that will ultimately be pushed to production once it is finalized.
I NEVER source control the DNN instance itself, that's just asking for pain.
This can be quite challenging, especially since some parts are user-data (which shouldn't be re-deployed on development) and other parts are dev.
There is a minimal guide to this here: https://docs.2sxc.org/abyss/enterprise-development/index.html
So I've been a developer on a one man team for a few years now. I came to recognize the benefit of separating all of the design, html, and css work into the hands of the more gifted individuals, so I started a business, made up of other long-time 1 man teams who were limited to static websites (that looked gorgeous). You can imagine what comes next.
We've been using Zend Framework (PHP applications for most applications, which separates most of the view code from business and data layers, but occasionally one of the designers or front-end guys has to tinker with a model or view script, and I'm starting to have coordination nightmares for who is updating what files and when so we don't overwrite anyone's important changes in the dev environment. (obviously waiting for stability before production deployment)
I work with NetBeans on my local, while the others use dreamweaver. What I'm looking for is a tool that can manage file versions on the dev server, allowing check in/check out, so nobody is working on the same file at the same time. (or better yet, merges changes)
Any suggestions on a good tool for this? Would a CI tool be better or a VCS tool? The only other option I can think of is to work directly on a development server, deploy to a simprod environment, than after testing, move to prod, but I like being able to develop behind a firewall before putting something on the internet. Any recommendations would be helpful.
Thank you.
You are looking for git. Perfect for managing versions and branches, deploying to the dev or prod servers, pretty much anything you can throw at it.
We have an application at work which is web-based and comes with a bundled web server (Apache tomcat), and is for network monitoring/patch management. It allows for personalisation, all sorts of rules, custom UI design using proprietary components and definition language, and even custom code to fire on events (based on Java).
I am in a team of several developers, each of who will be customising this app to meet various requirements. As it's a server app, not a codebase, what's the best way to setup a dev environment for >1 user?
If there is one single shared VM with this app, I don't know how good source control like TFS would work with this sort of system? I think also, developers working on various parts of the project may even need the same file at the same time (though TFS does do multiple check-outs).
What is the best way to develop against this sort of product? Bare in mind, even with personal VMs and an instance of the app, changes have to be merged to one central instance. Something keeps making me think about how app-virtualisation could help with this?
Thanks
If it is just an instance of Tomcat (even though it was bundled) couldn't you put the whole Tomcat directory and all of its subdirectories under source control? You just need to check in the non-binary parts, so exclude all the .jar, .exe, .tar.gz and .dll files when you check in. That's what I would do, unless I misunderstood your question.
I'm not familiar with the source control software that you mentioned. I have been using SVN (which is free) and TortoiseSVN as a client (also free). Just an option if your software can't support what I've suggested.
I've been tasked with setting up a version control for our web developers. The software, which was chosen for me because we already have other non-web developers using it, is Serena PVCS.
I'm having a hard time trying to decide how to set it up so I'm going to describe how development happens in our system, and hopefully it will generate some discussion on how best to do it.
We have 3 servers, Development, UAT/Staging, and Production. The web developers only have access to write and test their code on the Development server. Once they write the code, they must go through a certification process to get the code moved to UAT/Staging, then after the code is tested thoroughly there, it gets moved to Production.
It seems like making the Developers use version control for their code on Development which they are constantly changing and testing would be an annoyance. Normally only one developer works on a module at a time so there isn't much, if any, risk of over-writing other people's work.
My thought was to have them only use version control when they are ready to go to UAT/Staging. This allows them to develop and test without constantly checking in their code.
The certification group could then use the version control to help see what changes had been made to the module and to make sure they were always getting the latest revision from the developer to put up on UAT/Staging (now we rely on the developer zip'ing up their changed files and uploading them via a web request system).
This would take care of the file side of development, but leaves the whole database side out of version control. That's something else that I need to consider...
Any thoughts or ideas would be greatly appreciated. Thanks.
I would not treat source control as annoyance. See Nicks answer for the reasons.
If I were You, I would not decide this on my own, because it is not a
matter of setting up a version control software on some server but
a matter of changing and improving development procedures.
In Your case, it might be worth explaining and discussing release branches
with Your developers and with quality assurance.
This means that Your developers decide which feature to include into a release
and while the staging crew is busy on testing the "staging" branch of the source,
Your developers can already work on the next release without interfering with the staging team.
You can also think about feature branches, which means that there is a new branch for every specific new feature of the web site. Those branches are merged back, if the feature is implemented.
But again: Make sure, that Your teams agreed to the new development process. Otherwise, You waste Your time by setting up a version control system.
The process should at least include:
When to commit.
When to branch/merge.
What/When to tag.
The overall work flow.
I have used Serena, and it is indeed an annoyance. In addition to the unpleasantness of the workflow overhead Serena puts on top of the check in-check out process, it is a real pain with regard to doing anything besides the simplest of tasks.
In Serena ChangeMan, all code on local machines is managed through a central server. This is a really bad design. This means a lot of day-to-day branch maintenance work that would ordinarily be done by developers has to go through whomever has administrator privileges, making that person 1) a bottleneck and 2) embittered because they have a soul-sucking job.
The centralized management also strictly limits what developers are able to do with the code on their own machine. For example, if you want to create a second copy of the code locally on your box, just to do a quick test or whatever, you have to get the administrator to set up a second repository on your box. When you limit developers like this, you limit the productivity and creativity of your team.
Also, the tools are bad and the user interface is horrendous. And you will never be able to find developers who are already trained to use it, because its too obscure.
So, if another team says you have to use Serena, push back. That product is terrible.
Using source control isn't any annoyance, it's a tool. Having the benefits of branching and tagging is invaluable when working with new APIs and libraries.
And just a side note, a couple of months back one of the dev's machine's failed and lost all his newest source, we asked when the last time he committed code to the source control and it was 2 months. Sometimes just having it to back up stuff when you reach milestones is nice.
I usually commit to source control a couple of times a week, depending if I've hit a good stopping point and I'm about to move on to something different or bigger.
Following on from the last two good points I would also ask your other non-web developers what developmet process they are using so you won't have to create a new one. They would also have encountered many of he problems that occur in your environment, both technical using the same OS and setup and managerial.
I've been developing my first iPhone app part-time and would like to start using a more rigorous form of version control than I've been using over the past four months, i.e. copying source code folders to another directory and time stamping them.
I've used SourceSafe and Team Foundation System but I don't have a good idea of what version control systems (VCS) are available for the Macintosh. I've seen ads on SO for a Subversion front end but would like some other options.
Here's a list of my initial requirements:
Runs locally under OS X Leopard 10.5.7
Integrates with XCode 3.1.3 (if no integration, user-friendly interface)
Basic VCS features - check-in comments, branching, pinning
Advanced VCS features like build automation or reports would be nice but not critical at this time
Ability to handle multiple developers down the road (6-12 months)
Thanks in advance for the help.
Mercurial would be my pick for version control for a project starting as a solo project if you don't want to set up a dedicated server. Mercurial requires no server because it's a distributed VCS, every working copy is also a complete repository, so once you've installed Mercurial you are ready to go, just type 'hg init' in the root directory of your project and you're off.
It's perfect for working alone or with a small number of developers (i.e. no IT staff or sysadmins available), it has a utility that lets you quickly set up a temporary server for your local repository so when you meet up with people it's easy for them to clone the repository or share changes. You can also just give people copies of your repository over email or USB key or copy them over the network or whatever and reconcile changes to the copies against each other later.
For me Mercurial made the difference between actually using a VCS for personal projects and just giving up because it's too much trouble. Setting up a Subversion server locally isn't a huge deal but it's still enough trouble to make me not bother, and if you really want to be thorough you'd want to think about how to do proper backups, etc. With Mercurial at any point you can just back up your working copy to other media and you have a backup. I don't know if this really makes sense but Mercurial is a VCS that you can use casually and informally thanks to the distributed nature.
No Xcode integration, but having used various VCS' with and without integration I don't think it's very important as long as good clients are available. These days I've mostly settled on just going command line and it's refreshing.
Perforce, IMO, is right out. Aside from being a commercial product it is obnoxious beyond belief. It requires you to be connected to a server at all times or things become a major pain in the ass. So if you just want to work on stuff from multiple machines in multiple locations or if you want to have people on the project that won't be on the same network all the time it's going to suck. Perforce just constantly beats you over the head with the fact you are using Perforce, no other VCS I've used is so in your face and annoying.
Git is another option with a similar feature set to Mercurial that might be worth looking at. In my case I also do Windows stuff and Git's Windows support is supposedly crap so I went with something that works on all my platforms.
Build automation IMO is the build server's job, not the VCS' job, so if you want build automation find an appropriate build server.
SVN or Subversion is included with Xcode and is well integrated with it. As you grow to have bigger needs, you can use third-party Subversion servers and use the same SVN support over the network. If you don't like SVN, I think XCode supports CVS too.
If you're looking for something adequate, cheap, and expandable, then just mosey on over to the SCM menu of XCode, and check out what's already there. If you need help setting up SVN, just comment.
IT looks like subversion would be your best choice for XCode as there is already some guidence on getting that up and running with XCode here. Subversion addresses all of the features you are speaking of. Pinning specifically is a feature of Source Safe; however subversion can do tagging. Build automation is not a feature of a source control system, but source control systems are typically used in continuous integration server scenarios. I have not used it but from what I understand Hudson is a continuous integration Server which is gaining popularity and momemtum. You can find more information on Hudson here and here
SubVersioN (SVN) fulfills (most of) your requirements.
I'd also put in a vote for subversion since XCode supports it natively. I've been using it myself and have been very happy.
However I'd question your requirement to run the server locally. Sure, you can do that no problems with subversion. But wouldn't you be nervous about your hard disk failing?
I've been using Beanstalk to host my source code. It's free for up to 3 developers, you'll be able to upgrade your account once you grow, its fast and it's SAFE.
I just looked in Xcode (3.2, though, so it may not be exactly the same) and the options for source control integration are subversion, CVS and perforce.
Outside of Xcode, there are a couple of very nice GUI clients for subversion for OS X.
Subversion would be a good place to start, it seems.
All the cool kids are using distributed VCSes these days, apparently. You might want to spend half an hour reading up on git or mercurial (hg - my preference). There's no direct integration with Xcode, but they're easy enough to get into.
Perforce is now free for up to twenty users, but will be expensive after that. You might want to check it out, however. Xcode no longer supports native Perforce integration, though there are scripts and a plugin.