We are migrating from one domain to another, and I'd like to be able to keep my same workspace, user settings, history, etc.
Is there any way to change just my domain or log in name within Team Foundation Server?
I don't know the answer, but I do know enough about TFS to be a little bit frightened about it.
If I understand you correctly, you want to change the domain that your users are authenticating as but you want to keep all the same user id's pointing to the same accounts in TFS?
TFS is highly integrated with Active Directory, and stores AD SID's around the place. It also is pretty sensitive to changes in the AD configuration.
I seem to remember one customer that I know of who has done this before, but I cannot find details of it now. I think that your best bet is to call Microsoft Product Support and raise a support incident about it as I have a vague memory that there was some special tool that had to be ran - but I could be mistaken.
Good luck,
Martin.
I know your login name is done through your Domain Controller but I dont know how that will work with switching which domain your TFS is on. Are you trying to move which domain the TFS installation is on or which domain your PC is on?
Related
In IIS I want to deploy a sub application in a website. I really don't want to bother with having to update the root website's web.config with location tags all over the place.
Is it possible to direct the sub application to just totally ignore the root website's web.config?
Okay, so that's my question. The following is just additional information that could lead someone to offer an alternate solution I haven't thought of but if possible I hope you won't judge my post on the following since, as I mentioned, the above is my question... this is just extra information for the interested:
I am deploying several websites. Each website will have an admin application which will have the same codebase. I want the admin application to be available at site1.com/admin, site2.com/admin, etc.
In the past I did something similar on another project, but instead of having sub apps I did sub domains to another site... so it would have been like site1.admin.com, site2.admin.com, etc. Nice thing about this solution was the ease of just adding additional bindings for any new site (and the application would look at host name to apply proper theming, configuration, security, etc.). I would have preferred this solution again but it just won't work this time because we can't easily secure a proper domain name for that purpose and aside from that we would prefer the user stay on the same domain name anyway just from a marketing perspective.
So ultimately my goals are:
Have the web address be "sitename.com/admin"
Only deploy the admin application to one location
Avoid spending 2 days trying to figure out how to properly configure everything so that configs don't clash and then still end up with a
few errors I spontaneously find over the course of the next week and
eventually find one that requires me to reprogram a large section of
code in order to play nicely with the root website. (If you can't
tell, I may have minor PTSD from trying something like this a couple
years back).
I mean, what would be really super is if I could have admin be its own web application and have bindings like "site1.com/admin" and "site2.com/admin" but obviously that's not possible. But maybe there are some other straightforward solutions I haven't thought of yet?
I want to add a Ticket System to the web app I'm developing.
The idea is very simple:
Users can open tickets when they have problems and
the Admin can see the tickets the users have submitted.
I'm looking for a ticket system but I have found only systems that are external to the web. I want to add it IN my wep app.
¿Do you know any ticket system por rails?
Thanks
I think using some external gem like noted above would be either an overkill or a hassle due to mentioned bad documentation.
Judging by your problem description this is quite simple to implement.
Create model for tickets and associations with users (I assume you
already have users model fully set up).
Authorize access to tickets' actions depending on user status (admin
or not)
Create corresponding views
P.S.
You could have a look at Redmine code. It is an open source project management software written in rails. I am sure this could give you a good idea of how to build your own or even borrow bits of code from there (if the app license that you are building fits)
Maybe Simple-Ticket would fit you. Though beware the basic implementation and the fact that there is no documentation provided nor written specs.
Have a look at restrospectiva. It doesn't have any documentation though
I'm about to finish building a simple subscription based support ticket Web app. I'm setting up authorization. But since this it's going to be my very own Web app that I'm going to deploy I'm wondering about this.
Do you create a separate database per account opened?
Let's say you have this support ticket Web app. You have ONE and ONLY ONE account owner. Account owner can setup agents that can respond to support tickets. Also, there are customer roles that open support tickets.
So as you can see the database will contain users, support tickets and more.
What is the best way to go?
1) Create one database for the whole application? That way every time somebody signs up, everything is added to the same database with the other tickets and users data and everything else or...
2) Everytime someone signs up, create a separate database per account subscription.
I'm thinking that maybe option number 2 would be a best choice for security and data integrity purposes. If so, how have you gone about tackling this issue?
It sounds like what you want is Multitenancy:
Multitenancy refers to a principle in software architecture where a
single instance of the software runs on a server, serving multiple
client organizations (tenants). Multitenancy is contrasted with a
multi-instance architecture where separate software instances (or
hardware systems) are set up for different client organizations. With
a multitenant architecture, a software application is designed to
virtually partition its data and configuration, and each client
organization works with a customized virtual application instance.
- Wikipedia article on Multitenancy
This article while a little dated is the general idea of how I would go about doing it. Simple Rails Multi-Tenancy. It's clean and efficient and saves you from writing code that you don't need to.
You should go for option #1. Number 2 is (almost (there are probably cases where it is good, but I can't find one at the moment)) never an option.
You are right in security purposes (well, in a sense), but it also creates a lot of other problems that you will have to think about.
Having a different database for each user means that for each request (remember, HTTP is state-less) you will have to open up a new connection to the database, do whatever needs to be done and then close the connection again, instead of using the connection pooling that is in Rails. This affects the performance a great deal.
Administration will be a hassle the more databases you have. Also, having multiple databases on a server do require more resources than just a bigger database.
You would have to circumvent the entire connection handling in Rails since there it is usually one database per application. It is easy to change the database for specific models, but it adds additional places where things can go wrong.
Rails do have good functionality for scoping and handling of separating data within the same database, just for that kind of use-case that you are mentioning.
I am in the situation where I have been charged with making an application or extension to Umbraco that makes the backend users able to do a migration of their changes on the development site to the live site. This migration is supposed to happen once a day, or when the backend users press a button in the backend.
I am aware that Umbraco offers this in the Courier package, but apparently it doesn't work well enough for this case.
A few more details:
The development and live site both reside on the same server and so do their databases. The data will simply need to be transferred from one folder to another and the same with the tables in the database.
As I can see there are two methods of going about this.
1) You do a full migration, where you basically do a teardown of the live database and update it to the new version. You then copy over all the files you need as well.
2) You create a package containing the document types and so on you have changed on your developer site and load that package on the live site.
The problem with number 1 is that it seems you have to republish the entire site when you have done the transfer. As far as I have understood you can do this with a webservice, but I would prefer it if I could use a console app instead.
My question is then:
Is there a way to create packages programmatically and load them in the same way or what would be the best way to achieve this migration programmatically?
Any suggestions would be much appreciated as I am kind of at a loss for a way to do this :)
EDIT
I ended up actually doing a complete mirroring in the sense that I used Robocopy to transfer all the files that had been changed in the folders, and then I did a backup of the development site with a SQL command, and then I restored it on the live database using the RESTORE SQL command.
A few settings needed to be done in the SQL commands, but it runs smoothly and a complete transfer takes down to 10 seconds depending on the number of files that have been changed.
One last thing. If you want the changes to be visible you need Umbraco to be reloaded. This you can do by modifying the web.config file, either manually or by setting it's LastWriteTime programmatically.
You can always create a usercontrol that will handle the republishing of the entire site for you, this you can call from your console app.
You could also join the Courier 2 beta program, which is indeed good enough (for features anyway, I haven't tested it myself).
Another route could be to offer all of the nodes as a xml feed and use the scheduling feature of CMSImport to migrate nodes automatically.
This is a tough one, there's a lot of options an no silver bullet yet. I have good hopes that Courier 2 will be perfect for this and am eagerly awaiting its release.
It's an application that we use internally at the office that I would like to offer as a hosted service for anyone.
How can I do that without making major code changes?
The first thing that occurs to me is to have the app select which database to connect to based on the domain.
So each instance of the app would have its own database, but all instances would share the same code.
The only changes required to the code would be the database selection.
Is this approach maintainable? I've heard wordpress.com does this and that it offers a couple of advantages. I'm mainly looking to do it this way to avoid have to scope my entire set of database queries to a certain site within the same database.
Thanks!
The simplest way to do this is to clone the application, and create another server instance to handle it. This actually the way I handle multiple wordpress blogs on my server
Pro:
This process can be streamlined into a utility script.
Can be easily maintained if symlinks are used for the common code. IE: Everything but branding and some of the things in the config directory.
Cons:
- If you're using passenger it will require an apache restart for each new instance.
- Same if you're using Apache to route subdomains on different virtual hosts to different mongrel clusters.
However the better way comes from the question: Rails - Separate Database Per Subdomain
The method in the accepted answer is much more robust. It might require more changes than you're looking for, but it has all the benefits without the drawbacks of any other methods. Each new instance requires a new entry in the master database with the table name and other instance specific information. You'll also want custom rake task to build the database for each new instance.
I would suggest switching the database connection and adding a view_path based on the domain, I have posted code in this question.
I hope this helps!
I wouldn't do this with multiple databases as you mentioned. Keeping all your schemas/migrations in sync with all the db's could become painful.
I would look into simply making it a multi-tenant app where you have some sort of "Account" model and then all your existing models are scoped to it ... in other words, if this was a blog app, your Account has_many :posts, etc.
With this approach, you can identify accounts by subdomain ... have people choose their subdomain when they create an account and go from there.
It's pretty straightforward to do. If you need add billing into the mix, you might look at the SaaS Railskit (which handles all the signup and subdomain stuff) or Chargify.
You can also identify accounts Twitter-style ... with http://myapp.com/someuser