Related
I'm currently looking to start setting up nightly builds with TFS and our company has never done this before. I'm looking for some pointers on maybe where to get started, what I should look out for as well as structure of solutions.
Background
Current TFS source location has 2 web projects, 5-10 windows services, 10-15 supporting dlls. These will continue to grow.
Currently there are solution files for each web project and each windows service. Each of these solutions contain the supporting projects (internal dlls) and also the correlating unit testing projects.
All of our external dependencies (log4net, nhibernate etc) are managed by NuGet and are in a folder within TFS called packages
Some of my questions include but are not limited to
Should I have a master solution file that contains all of these projects? Maybe this is easier when setting up nightly builds?
I'd also like to run the unit and integration tests as part of the nightly builds. Is this just additional configuration on the build server?
What tools are involved when setting up nightly builds with TFS?
I'm not necessarily looking for complete answers but it would be great if someone could point me to some good resources (books, websites, blogs)? Like I said I'm really green as far as nightly builds are concerned and I just want to make sure I start off on the right foot. Hopefully I can learn from others mistakes.
Here are some simple "answers" to your 3 questions (though I agree with the comments above that this isn't the most answer-able SO question):
An good read on creating reliable builds in MSBuild : http://msdn.microsoft.com/en-us/magazine/dd483291.aspx
Yes running tests is just an option in a TFS Build Definition, you can configure a few options in addition to "on/off" : http://msdn.microsoft.com/en-us/library/ms253138.aspx
You can also use TFS Lab management and test agents to execute tests in a different manner: http://blogs.msdn.com/b/lab_management/archive/2009/05/18/vsts-2010-lab-management-basic-concepts.aspx
Configuring TFS builds : http://msdn.microsoft.com/en-us/library/dd647547.aspx
I'm undecided about CRM at the moment. It's a great tool for the business users but so far for development it's been a bit against the grain. The next problem I need to tackle is how to easily source control javascript used within forms. We use TFS for our source control.
Anyone had an experience or have any ideas on how to do this?
Obvious choice would be to copy and paste the JS in to your source control, but it's also an obvious pain in the rear.
A couple of things that we do in our projects:
We use the Web Resource Utility included with the CRM SDK (actually a modified version of it) to deploy JavaScript web resources to a particular solution. Makes it very easy to keep script files checked in to source control as normal and avoid copying and pasting.
We wrote a custom HTTP Module that we use on local deployments. It intercepts requests for JavaScript libraries and redirects them to a location on local disk. That way, we don't have to actually redeploy the web resources as we test, just the JavaScript files to disk. (Note that this would be unsupported in a production environment. We just do it in our development environments to ease the pain of JavaScript deployment).
I answered a very similar question here - Version Control for Visual Studio projects and MS Dynamics CRM (javascript)
My choice for source control is TFS holding each of the 2011 JScript libraries.
We try to mirror the file structure that Dynamics uses for Web resources in a basic Library project. So version control works as normal, we just don't use the output from the project.
You can also try using the new "CRM Solution" project template (installed from the SDK) and have the ability to deploy from the context menu of the project.
I've had some issues with the template but something to check out.
Hope this helps.
You can take a look on my answer on my own question here.
MS Dynamics CRM 2011 SDK has solutionpackager.exe utility what could split all CRM resources into file tree and you can store them either in git or in tfs.
Any web resource in CRM 2011 is a pain to manage. We just end up doing a lot of copy pasting in and out of TFS 2010 (which has actually caused some problems with poor pastes).
Currently out of the box there isn't an easy way to do it.
Only worry about this if you really need the ability to go back to old versions of web resources. I've found that I don't often have to do this. Remember that the web resources are stored in SQL Server just like they would be if you put them in TFS, so as long as your CRM database is being backed up, you won't lose the web resources. In traditional development, it is important to keep the source in TFS because you can't easily get back to it once you compile and release. With CRM development, your web resources are mostly HTML or JavaScript, so you can always get at the source.
If you really need version control, why not build a quick little console app that downloads all customizations every night and stores that zip file in TFS? True, it wouldn't be as easy to get at older versions, but you should gain a lot of productivity by not having to manually keep TFS in sync. This also has the benefit of storing all customizations in TFS, not just web resources.
Silverlight is the obvious exception here - I would definitely store Silverlight web resource source code in TFS, because it is a "compiled" web resource. You are already in Visual Studio, so TFS is a natural fit anyway.
Hope that helps!
I haven't thought this through to completion, but it seems that if nuget is a tool for managing the inclusion of packages in a known location, could it not be used as a deployment tool for web servers (a website being just a very large package itself)?
A service running on the web server would ping a nuget server for updates, and install them when available. There would have to be some additional management (recycling app pools, making sure that all your webservers don't update at the same time etc.), but I think it could work?
Any thoughts?
Yes that's definitly on the roadmap for openrasta/openwrap, so it's not a crazy idea. Some people already have done some of that work themselves.
This sort of thing is usually known as a Continuous Integration (CI for short) setup. You could probably cobble something together with Nuget but there are already some pretty good tools out there. Cruise and TFS to name a couple.
If you're looking for a mad scientist project though, carry on and let the community know what you come up with!
I'm just learning how to do things, and want to start using some sort of version control for a web app.
What's most appropriate for deploying a python or php web app on my own? I'm using linux and have a linux server.
Thanks!
SVN, but you need to be able to easily deploy your webapp with SVN.
Since it is not always a simple task, so I just point out this article which may be of interest for your project.
General principle:
Configure Apache on your development server so that it picks up your checked out working copies as separate subdomains. Using this, you can simply make a checkout of your project and it will automagically be up and running. No need to touch the Apache configuration. You need a DNS wildcard entry so that all subdomains of dev.example.org go to your development server.
The only problem with using the above Apache configuration locally is the DNS wildcard. Unless your desktop is assigned a hostname by your network's DNS server and you can set the wildcard there, you will have to make do with your localhost address. You can install dnsmasq to act as a local caching DNS server and put the wildcard on your own machine
Use dnsmasq so you can achieve the same effect on your own development machine. That way you can develop your web applications locally and you won't need a central development server. In my examples I will be assuming you use subversion for your version control, but it works virtually the same with other version control packages, such as git or bazaar.
Note: (Humor)
This other question on Subversion allowed me to point out to this article about publishing its (source-controlled) data into production, with in it probably the ugliest diagram I ever saw on the topic ;-)
If I had not bumped into git, I would've doubtless gone with SVN. Having said that, I would recommend git.
Nowadays, I would certainly go with a distributed version control system. Setup is faster since you don't need to set up a version control server and everything, all you usually need to do is initialize a certain directory within your development box for version control and you're good to go. They also seem like the way to go these days. If it were 2001, I would recommend a centralized system like Subversion. But it's 2008, everyone is moving to distributed systems and user interfaces and supporting tools tend to get better.
Here are some suggestions for you:
Darcs: Easy to learn and has all the features you will usually need
Mercurial
Git: Powerful. May take some time to understand but evolves rapidly
All three of them should be readily available in your Linux-based OS through the usual package management solutions.
SVN is great.
Nowadays the hype around DVCS.
I prefer Bazaar.
Because of it's name, the support, the feature set, and it works well on my window$ machine too.
I'm using unfuddle.com and I love it. It's free for a one person web app
The answer really depends on your way of thinking. I personally had problems switching to subversion from SourceSafe. If you come from microsoft shop, I'd suggest using SourceGear Vault, it is free for <=2 users. If you come from non microsoft area, then using subversion would be preferrable. Also please consider git if working on linux.
HTH, Valve.
Personally I use monotone, learning a DVCS is definitely the way forward.
For a one-man job, pretty much any revision control system will do the job. It's when you get into multiple people, and past that into multiple repositories, where there start to be differences.
Given that, I'd go with whatever Free Software system your development environment supports best. I see Subversion and Git mentioned and both are fine choices.
SVN would been my first choice. If I have to take a second choice I would go to CVS.
One of the most popular models out there today is Subversion. It's generally easy to setup & configure and is able to handle multiple platforms.
SVN. If one does not need concurrent access (which is your case), it is VERY easy to setup as no server is required at all. Definitely your weapon of choice.
I wholeheartedly agree with SVN. Command-line SVN is quite easy too.
While I like svn a lot, I've found mercurial handy for having the whole repository locally. (the same goes for git, but its interface is a little less polished in my opinion.)
I'm not able to answer the question as asked, because I don't develop on a Linux server.
But maybe this experience has a counterpart in Linux world.
I use a local-on-my-LAN-only IIS server (actually on an old laptop that no longer travels but works as a little server). I have VSS installed on that server too. There is an integration between the IIS Server, the FrontPage extensions on that server, and the VSS.
The upshot is that I can use FrontPage to build and edit my site and build a development image that is always backed up in VSS, and I can check out, check in, and do all of that from within FrontPage.
Now, the way I publish is I take advantage of the sharing capability of VSS so I have a deployment image that shares with the project that is actually an IIS web site. I have a deployment-image directory that I can transfer the latest checked-in material to (material that has not changed is not updated). I then deploy the deployment image to the hosted, public web site using FTP (again, only transfering new and updated files).
I present all of these details to suggest what might be the use-case of interest, even though a different solution approach is needed with Linux.
If I wasn't using a tool that integrated with the web server and also the source control at the server, I could do something similar by checking the VSS material in and out of a local directory and then pushing the updated VSS project to the IIS server web-pages directory hierarchy. The workflow is a little more clumsy. In this case, I would not edit pages directly on the development web server unless I could lock check-in pages as read-only or something.
Does this suggest anything that might be appealing in the Linux server case?
Definitively Mercurial is a good choice, quick, easy to use, perfect for working alone, or with multiple other developer, perfectly multiplateform, handles merges, branches, etc. very simply, plugin based, there are great tools out there such as nice IDE plugins (notably Netbeans and Eclipse).
Robust, it works just as you a expect such a tool to work, not like SVN (and I have years of day to day)...
Both Sun, Xen and Mozilla host all their repos on Mercurial. We're currently moving from SVN to Mercurial after a 6 month daily test, without any regret.
I once used Perforce and was impressed with it. There's GUI and command line versions and it supports Windows, Linux, Mac and Unix for both the server and client. It integrates with Eclipse and has APIs for writing your own client applications (C/C++, Ruby, Perl, Python) It only supports two users and five workspaces before you need to buy licenses though (but that is within the scope of this question).
Subversion is a good choice. For the client, there's TortoiseSVN (http://tortoisesvn.tigris.org/) that integrates with the shell and lets you do things with a right click on a folder. For integration with Visual Studio (I'll assume that's your environment) there's VisualSVN (http://www.visualsvn.com/) and AnhkSVN (http://ankhsvn.open.collab.net/). For the server there's a one-click installer you can find here (http://svn1clicksetup.tigris.org/) that does the setup in a snap. VisualSVN also has a (free) server that you can use which provides it's own web access and security (rather than using apache) and has a mmc-snapin for managing/creating repositories and users.
CVS - No, I'm not joking. Not that it is better (it is not) or the simplest (it isn't), but it really doesn't matter at the end of the day. The important thing is to get started with ANY version control system even if it is a one-developer shop, even if it is CVS.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
How do you manage your project life cycle?
For example: Do you start with a template? Do you use versioning such as SVN as the authoritative source? Do you archive the projects, if so when and how? When a project is revived (work resumes), how’s that handled? Do you use automated scripts to do things such as create IIS sites, DBs, archive, launch, etc?
Of particular interest is management of many projects at varying points of development.
Development: We do not start with a template, because the world changes quick enough to make template maintenance a full time job. We do encourage everybody to use the same IDE (Eclipse), so that they can help eachother with their environments.
Project Management: We are using GForge to manage our projects. Sourceforge is slightly better, but GForge is much cheaper and has a different licensing fee model. GForge incorporates CVS, SVN, Document storage, Issue trackers and integrates everything nicely. This makes it easy to see where the project is at. Open issues, and closed issues with connected code changes, everything is integrated.
Versioning: Although we tried SVN, we switched back to CVS because it fits our needs better and works fine.
Backups: Our GForge server, housing all our projects and sourcecode, is running on a VMWare EX server. Backups are done daily on VM level and we make VM snapshots if we feel that we need more frequent restore points for some reason.
Reviving projects: This is very common in our business. Every project has all it's libraries and build requirements in CVS. The project always has an up-to-date development manual which describes all the steps to get a development environment running, and has a chapter with all the things which are not default, to pay attention to. We try to build software in an as-default-as-possible environment so that developers don't have to spend days tweaking their settings.
Nearly all projects are built using Maven, which also makes life easy for our developers. Ususally reviving a projects only takes a few steps:
Download eclipse
Connect to CVS over SSH (extssh is built into Eclipse)
Check out the project (default "Check Out" option)
Run "Maven Eclipse" and refresh Eclipse
Run unittests in Eclipse to see if everything is working.
Builds: All our projects are built on a seperate build server. Every morning the build server does a complete build and tags CVS if all unittests succeed. During the day, hourly builds are made and when there are failures the team automatically gets an email. Usually we use one build server per project, and it is a simple luntbuid server (Linux, Tomcat, Luntbuild).
Both the buildserver and sometimes even the developer machines are VM's. This makes reviving a project really easy. Get the VM from the fileserver, start it up, and you're good to go.
The build server creates daily sites which show unittest coverage statistics, complexity measurements, CVS activity and developer activity (who changed what and when).
All our software comes with self-building database scripts built in. Point the config file to the database, start the software, and it figures out what it needs to do to the database itself. This really comes in handy because the buildserver can just start the software. No special steps needed. Our customers are also happy, they never need to worry about their database, or upgrade scripts.
The whole project lifecycle is managed, documented and tracked in GForge, with the addition of some external spreadsheets for budget tracking because that's simply easier.
Wether you have an integrated project server or not, I think it is really important to have a system. This enables you to switch developers between projects without them getting lost. It saves time. Particularly when a customer comes back to you after 2 or 3 years for modifications on old software (yes, that happens).
All the stuff we use is open source (you can even use an open source fork of GForge). It's not in the tools, it's how you use them.
It would depend on the nature of the work. When working at home for private clients, I start by opening a folder for the client with a bunch of standard documents, which I customize, such as contracts, invoices, reports, requirements, testing, code repository, etc. As the project develops, I add/modify the directory as required.
If I had to go back to a project, I would reopen that directory, and for any non-common components, create a new directory. For example, if my client had a web application built, and now they need a second application, I would use the same directories for invoices and contracts and create new directories for the code base, requirements and testing.
In terms of backup, I archive the work at any point where I've reached a milestone, with the exception of code, which I back up daily at a minimum. At the end of each project, when I close a contract, I take the entire directory and compress it and store it on a remote server.
i create folders containning the project stages like "initialize software process" on were we placed docs like the bussiness proposal, we use another one for requirements another for the construction,releases,one for meetings minutes, and so on.
We keep those under a subversion repository but it really depends on what metodology you are using, also it depends on how do you handle the configuration management and how organize you want to be. and yes we use template for most of our artifacts so we assure in some way the quality of our products.
As for source code, we have it all in a Subversion repository. After each release, we make a branch - new features only get added to the current branch (on which the next release will be based), critical bug fixes are done in the current and the old branch (so we can deliver hotfixes for the version the customers currently have).
As for all documents belonging to a release - from the planning & resource sheets to specifications, testcases, user and technical manuals for the software we create etc. - we store them in a Sharepoint portal site. The advantages of this Sharepoint site is that users have access via a website (so no need to grant management access to your repository ;-), you can finely control the access rights, and you can turn on versioning. We also use tagging to mark whether a document belongs to a specific release (e.g. service pack xy) or product, or whether it is generally valid.
Concerning scripts, we use several to perform e.g. nightly build plus unit tests (we usually do that for the last and the current release), but also to deploy the complete software solution (including IIS site creation, database data model upgrade,...) on out test servers. These are nant scripts using lots of variables for paths, version numbers etc. so it is very easy to copy and modify them for a new release.