I am pretty new in source control installation and inner workings, although I already had worked with TFS, I have no clue about how to make it work from scratch.
Basically I want to have some source control in my personal VS2010 projects, so I may see the code evolution, rollback and etc. but I am a little lost about how may I set it up...as far as I can see, I have to have a Team Foundation Server running, so is it possible to install one in my PC? Is it free? Or there is a better way for doing it?
I just want some simple tips like "hey man, here are the steps you should follow" or "this is impossible, you have to have a server" or "follow this tutorial"
Thanks a lot guys!
[Disclaimer: I work on TFS and tfspreview.com]
If you are looking for ease of set up and a free offering then I would highly recommend tfspreview.com. While it is still in "preview" mode, it is certainly usable and safe. The site itself also has a great "learn" section to help you get started. The best part is that it has features available that haven't even been released in the on-premises product yet and the development team is consistently adding new features.
If you have any questions about the service, I'd be glad to answer them.
Oh, one other note, to connect to the hosted service you will need to install the VS 2010 compatibility GDR but that is free also.
GIT is a brilliant source control that has allot of easy to use functionality. In fact that have an extension for VS2010 as well. Check under the extensions menu and install the GIT extension. You can them commit and update from within VS itself. Super easy to use!
Enjoy :)
Related
I'm looking for a (if possible) web service/local server download of some kind that would allow me to share code snippets with my team at work. To increase the productivity of our team it seems like the best way to do this is for everyone in the team to submit code snippets with their name. So a way to share snippets on a local network (in the team) and a way to tell who submitted which code snippet when. I've looked a bit and I've found https://snipt.net which is fine but isn't really setup for a team from the looks of it.
If you are using git for version control, and you are using version control right? :). Github is the defacto standard in my opinion for sharing and managing code. They have free and paid plans that are very affordable. The also to subversion hosting so you are covered on both fronts.
I've been trying to find a guide on how to get Team Foundation Server to turn on a lava lamp or traffic light to indicate the status of the build. I want to set up something that's visible right across the office so there's some peer pressure to encourage developers not to break the build; but I also want it to be fun.
There's a lot of examples for CruiseControl that use X.10 devices which seems like a good way to go. But I can't find anything similar for TFS. I'm sure that somebody must be doing this somewhere...?
Using X.10 has one problem in that it requires a serial port - but our TFS is completely virtualised in a data centre somewhere. Maybe there is some way to trigger the traffic light via an email?
Any advice appreciated. Thanks.
The TFS have got a nice API for getting the status of recent builds. You can use the API and design your own fun system.
Also take a look at:
TFS Build Monitor
TFS Build Light
At some point I had stumbled upon this youtube-video, where Martin Woodward presents Brian, the funky TFS-build bunny. Might be worth checking. It might also be worth checking this SO post.
The TFS API's are terrible they're a pain to do yourself. You could start with this open source project on Google Code: http://code.google.com/p/siren-of-shame/. That project is designed to work with a couple of different build servers, but everything is broken out, so you could start with the TFS 2010 project (TfsServices.csproj). Or if you don't want to do it all yourself that project is designed to work with a USB Siren that they sell (see http://www.sirenofshame.com/).
I'm looking for guidance in setting up a corporate source server, but when I google this topic the best I can come up with is articles and walkthrough concerned with configuring VS to use microsoft's public symbol servers for use with debugging .NET assemblies.
Provided for background info, the environment I'm concerned with using is Vs2010/Tfs2010. Basically, the workflow I'm looking to facilitate is this:
1) customer reports problem with application
2) application of the appropriate version is installed on a virtual machine
3) developer repros bug attaching to process on virtual machine and leveraging source server (symbol server?) on corporate domain. This is the step I'm concerned with.
4) developer pinpoints problem fixes bug in workspace.
5) developer performs a dll swap on VM to test changes? (side topic, not sure on this)
6) normal development/source control workflows.
Any advice is welcome!
Edit: since writing this, I have stumbled on this article, which is a nice writeup on the configuration of source server for TFS 2008. Has anyone adapted this for Tfs 2010?
Here is an article about setting up a Symbol Server, for your own company. It also details how to add your own symbols and binaries to it and how to use them for debugging.
The article is from 2006, but the advice should still apply.
You should be able to follow your workflow with this setup.
Here is another article explaining the use of symbol servers.
1) customer reports problem with
application
Several ways this can be done. If your customer is external to your organization, you'll probably want a custom web front-end that ties into creating workitems via the API. Otherwise, you can use Work Item Web Access, which is included with your TFS installation.
2) application of the appropriate
version is installed on a virtual
machine
For this, you're probably looking at Visual Studio 2010 Ultimate and the Test and Lab management piece. Getting set up to use this is probably outside the scope of a SO response.
3) developer repros bug attaching to
process on virtual machine and
leveraging source server (symbol
server?) on corporate domain.
Again, Test / Lab management.
4) developer pinpoints problem fixes
bug in workspace.
TFS
5) developer performs a dll swap on VM
to test changes? (side topic, not sure
on this)
Development branch build with automated deployment. May be able to do this with Test/Lab management, or may have to do some scripting within your build. Scripting installs is relatively straightforward with TFS custom actions.
6) normal development/source control
workflows.
TFS source control and work items.
Installation and initial configuration of TFS is relatively straightforward with TFS 2010. Best practices will probably require a lot of reading and a mentor / consultant or two to get you through it.
Items 2 through 5 are normally handled manually by the developer. How they go about reproducing and debugging the error is not something any source control system can help with.
For everything else there is TFS.
With TFS you can pin builds and pull those from the build server as necessary for redeployment. You can also branch releases, make bug fixes in those branches, and roll those fixes back into trunk.
I think I have something to help you out... Here's a bunch of information about Symbol Server and Source Server support for TFS 2010 specifically wrapped up together: http://bit.ly/SymbolServerTFS
Let me know if there are any additional questions and I'll get them updated in the blog post!
I would like to know if you could share some (trusted) sources of information (books, URLs) that you consider the most relevant for learning Windows Installer. They could be for starting on this technology or for an advanced or professional level of knowledge.
Where can a future deployment engineer start and where can he/she go to keep on the right direction (step by step)?
I'm obviously biased but I think my blog and the WiX toolset are good ways to learn:
http://robmensching.com/blog
http://wix.sf.net (click on the Manual or Tutorial links on the right)
Some people like Phil Wilson's "The Definitive Guide to Windows Installer" but I never read it. I learned straight out of the MSI SDK.
I did 7 years of writing InstallScript installers before ever picking up MSI. While there is a huge difference between procedural script-driven imperative installs and data driven declarative installs, they both do the same fundemental thing: deploy software.
I became an MSI Expert but studying everything I could on the domain, writing LOTS of installs and by blogging for 7 years and answering over 4,400 posts on the InstallShield community forums. The only way to go in my book is to have been there and done that.
So the first step in your quest should be to understand the Windows Platform and related technologies very thoroughly. These evolve over the years but you should get a decent understanding of:
Fundamentals
Registry
FileSystem
NTFS
ACL's
DLL Types ( Win32, COM, .NET Assembly)
Win32 API
.NET Base Class Libraries
Service Control Manager Drivers ODBC
SQL IIS Active Directory ( GPO, LDAPand so on )
Global Assembly Cache
WinSxS Cache
DLL Hell
Good and Bad Installer Behavior
The second step is
Tools
Now let's start to writing installs. As Leslie ( Easter I assume ) said in another answer, pick a tool and learn how to use it to accomplish the above things. But don't stop there, as soon as you can go to the next step.
MSI
Start digging deep down into how your tool is working behind the scenes as soon as you can. Just as you can write C# in .NET and look at the IL with ILDASM, learn to use ORCA and see what is happening. Read the MSI SDK. Yes, it's rough and cryptic but I spent 3 months commuting beween DC and TX and I spent at least 16 hours a week traveling away from internet connections but nothing except the SDK to read. Read it, know it, live it... the cryptic help topics will eventually start to click and become second nature.
And finally, read my blog: DeploymentEngineering.com and every other blog you can find.
There is not a simple answer. The primary reason is that most install developers use a specific tool which in turn hides the bulk of Windows Installer behavior. While it would be nice if those developers had an in-depth knowledge of Windows Installer, that's not the case.
My suggestion would be as follows:
Focus on a specific tool. Many of the development environments offer a trial period and some are free. The on-line help for these tools plus the act of building some sample packages will be a useful process.
If practical, consider taking a training class for the tool. I know Flexera sells their basic and advanced InstallShield course manuals. They are a bit over-priced, but it does include need-to-know Windows Installer specifics. The problem you'll run into is that most documentation is specific to the tool without explaining a lot of the connectivity to Windows Installer.
You'll need the Windows Installer SDK -- in addition to the help file, there are some interesting tools and VBScript scripts. Orca is one tool that is included with the SDK and there are similar tools on the Internet (SuperOrca, InstEd, etc.). The SDK is not a great read but it is a great reference. As you come across specific questions regarding Windows Installer use the SDK help file to understand the deeper internals.
Google 'windows installer blog'. You probably don't want to hear that, but there are many great blogs available that cover many bits and pieces of Windows Installer. Make sure you pick up the Windows Installer Team blog.
No matter what path you choose, you'll find learning Windows Installer to be a hands-on process. I hope this helps!
I'm also biased, but this might be helpful. I recently revisited WiX for a real-world Windows Installer project and wrote up my solution which ultimately plugged into a continuous integration server.
The steps in the article take you through using WiX, localizing the MSI, and creating a bootstrapper for installing any prerequisites.
For learning, Tramontana's tutorial WiX helped me a lot.
A nice little blog post about how to debug custom actions is WiX and DTF: Debug a Managed Custom Action and how to generate an MSI log.
xdebug is widely used by developers and since xampp is meant to be used in development environment i wonder why it doesnt come with xdebug installed?
so annoying to have to do it manually all the time.
For one thing, some people might prefer the Zend debugger.
For another, XAMPP is a free product; the maintainers aren't getting paid for their work, so features aren't driven by user desires. If you want the feature, request it or (better yet) offer to add it. This is basically the same as the answer to "Why doesn't open source project X have feature Y?"