I am enrolled in Infrastructure management services(IMS), but I have less understanding of the domain. Is it same as the DevOps, if not what is IMS?
No. IMS is tool (Ops tool). DevOps is combination of tools, process and culture.
No , Not at all , although the roles and responsibilities cannot be defined , but devops has a broader role and has to be an intermediate between developer and operations engineer . Infra services are handled by infrastructure engineers who have better role in managing and creating IT infrastructure for a company . They have no idea about the software development and if there is a code error or config error , they could not find and correct the error , but a devops knows whole about the code as well as the deployment of that code in the infrastructure of that company . so it has a broader role . I have work closely with both of them but i never had an opportunity to be in any of the roles , so my answer might be partially correct . However , these both are just job titles which look out for nearly same kind of skill sets with a minor difference .
Related
I have worked with TFS for server years. We will move to Azure DevOps in next month.
After go through some docs, got some questions in below:
Why we call an organization for a url not account?
Why Azure DevOps only have one collection (default collection) unlike TFS server?
If one organization corresponding to one collection, when we move TFS to Azure DevOps, do we have to create multiple organizations for multiple collections?
This is a problem left over by history, some old docs/blogs may not updated timely.
For example, in documentation:
To sign in to your Azure DevOps account at any time, go to https://{youraccount}.visualstudio.com.
… should become:
To sign in to your AzureDevOps organization at any time, go to https://{yourorganization}.visualstudio.com
This change rolled out with our Sprint 137 Update:
Adopt the word "organization" when referring to a collection of projects in Azure DevOps
We've made a change to our terminology when it comes to referring to a
collection of projects in Azure DevOPS.
Previously we used the term "account" but have found that this has
caused a lot of confusion for the broader developer and open source
community. We've chosen to replace the term "account" with
"organization". You'll start seeing this change roll out in
documentation and in-product with this Update.
You account could create or be added in multiple organizations, for example:
As for moving TFS to Azure DevOps, create multiple organizations or not, it's based on your company's need. We suggest to do this if you use TFS Database Import Service
It provides a high fidelity way to migrate collection databases from
Team Foundation Server (TFS) to Azure DevOps Services. It's
recommended that you download the migration guide if you're
looking to use this service to import your collection(s).
The guide
serves as a walk through of the different steps involved in an import.
Providing best practices, checklists, and helpful tips to make your
import as easy as possible. The guide should be used in conjunction
with the more technical documentation referenced below to successfully
import to Azure DevOps Services.
Is there a way for our development team to point Visual Studio at an instance of TFS on another domain?
Pretty green when it comes to Team Foundation Server and not sure if this should go in the overflow that handles IT admin stuff (from my understanding stackoverflow is more code related).
We just got bought by another company and they want us to use their TFS that resides on their domain. We are working on getting to one domain, but in the mean time we still have two separate domains that talk enough to get by.
Just as Daniel said, just make sure there is a trust relationship between the domains.
Generally if you can access the TFS that resides on another domain with you current domain user, then everything should be OK.
More information please see Trusts and Forests Considerations for Team Foundation Server and Grant the Allowed to Authenticate permission on computers in the trusting domain or forest for details.
You can also reference this related thread : TFS Cross-domain authentication without trust
I am in a little bit confusing situation. Below diagrams are supposed to tell the case:
I had 2 different tfs servers serving to 2 different teams on my company. The users were local on those servers. So, no active directory, no central control. Hence we decided to merge these 2 servers into 1 TFS.
Now I have 1 big TFS server containing all the collections, without any problem at that level. But as you can see from the users names, the users are imported to this new server with their local computer names - A\user1, A\user2, B\user3, B\user4. Which violates my sense of harmony.
What I want to do is, install an Active Directory service on a new machine, and have all my users included in this new domain as below:
My ultimate goal is to use the same users, only changing their netbios names like C\user1, C\user2, C\user3, C\user4, in order to keep old informations in TFS valid.
Microsofts documentations calls the first step I have achived so far a "Hardware Migration", and the second step as "Environment Migration". Then tells to not to do them at the same time. So I completed, the hardware migration, and now I need to do the environment migration, but since I don't have a deep knowledge on this domain things I am taking it slowly.
I haven't installed Active Directory yet, since I don't know what I need to change beforehand.
My questions are:
What I am dreaming is possible?
How can I achive it?
Environment-based migration scenario means changing the domain of the TFS deployment, whether it's a domain name change or going from a workgroup to a domain. So what you want can be achieved.
You can use Identities command to change the security identifier (SID) of users and groups in your deployment of TFS. This command supports the following scenarios:
changing the domain of your deployment
changing from a workgroup to a domain (your scenario) or from a domain to a workgroup
migrating accounts across domains in Active Directory
Command:
TFSConfig Identities /change /fromdomain:DomainName1 /todomain:DomainName2 [/account:AccountName] [/toaccount:AccountName]
More information is described here: https://msdn.microsoft.com/en-us/library/ms404883(v=vs.120).aspx
I have figured out that TFS 2010 has the following web service endpoint
http://tfsservername:8080/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx
Are there ones to get a feed of check-ins, work items and other TFS items?
Update: yes! Visual Studio Online introduced a new REST API, and on-premises installations of TFS 2013 have access to this new API.
In versions of TFS prior to TFS 2013:
tl;dr: Not in any way you're going to want to consume.
Team Foundation Server does expose SOAP web services that the clients use to talk to it. However, it's not something that is publicly documented, it's not supported by Microsoft (meaning they can, and will, change version to version) and, quite frankly, it's remarkably unlikely that the effort required will be worth the result.
Although the web services are well designed, some of the web services require a significant amount of client state. This is particularly true of the work item tracking web services. The clients basically contain an entire "rules engine" for processing and verifying changes to any fields. The client must, basically, be able to understand the process template and process all these state changes before submitting an updated work item back to the server. The server will also run the rules and verify that the client made only legal changes.
The rules engine is not exposed publicly. You would have to reverse engineer it.
This also makes some underlying assumptions like your web services stack can successfully speak NTLM2 and Kerberos properly (most can't, outside of the .NET web services stack, although some an support NTLM version 1 to some degree, which will only give you the illusion that you should be authenticating.)
It's therefore strongly suggested that you just use one of Microsoft's APIs for accessing TFS, either the .NET or the Java SDK.
(I actually worked for a third-party company that successfully wrote a Java front-end to TFS by talking to the web services. It was a fair challenge for us -- especially the work item implementation -- and this was the full-time job for several of us. I wouldn't recommend it as a side project.)
Just like Edward mentioned, the TFS web services aren't meant for public consumption.
On the other hand, you might want to give the "OData Service for Team Foundation Server" a try.
It offers a really nice REST-like interface - thus callable simply by issuing HTTP requests, just like you were willing to do with the web services.
To learn more, check this blog post: http://blogs.msdn.com/b/briankel/archive/2011/10/26/odata-service-for-team-foundation-server-2010-v1.aspx
I don't know squat about TFS, other than as a user who has performed simple check in/outs.
I just installed it locally and would like to do joint development with a friend.
I was having trouble making my TFS web site on port 8080 visible (the whole scoop is here if your interested) and I wonder if it could be related to the fact that TFS is probably using Windows Authentication to identify the user.
Can TFS be set up to use forms authentication?
We probably need to set up a VPN, though that's a learning curve too.
To use TFS, do our machines have to belong to a domain?
We're not admin types, though he is better than me, though I would be interested in any feedback or advice on which path is likely to pan out the best. I already got AxoSoft OneTime working in this type of an environment and it suits us well, but I am tempted at all the bells & whistles with TFS and the ability to tie tracked bug items to code changes.
As far as finding a good way to share code, do sites like SourceForge allow one to keep code secure among members only?
It does not need to be installed in a domain. I'm running TFS at home within a workgroup on a virtual machine.
Create a user on the machine that hosts TFS. Let's assume this machine is named TFS-MACHINE. Grant that user appropriate Team and Project rights.
When connecting to TFS from the remote machine, the user should be prompted for a user ID and password. They should use a User ID of TFS-MACHINE\username and the appropriate password.
Regarding external spots to host code. If you're looking for cheap/free, you can look at something like Unfuddle, which supports SVN and Git.
If you're looking for hosted TFS, the only place I've been able to find thus far is SaaS Made Easy, but they can start getting a bit expensive, depending on the number of users you have.
Keep in mind if you're going to host locally that you'll still need to do things like periodic backups, etc.