CODEWITHSUNDEEP
gittfsdevops
RandomHandle
RandomHandle

Reputation: 651

Terminology: What "environment" is Team Foundation Server in?

I am starting to learn about DevOps -- TFS (Team Foundation Server) in particular -- and want to make sure I have the correct understanding of terms.

If the the local copies of my C# and SQL projects are the "development environment" and the published projects that the users interact with are the "production environment", how would we describe the "master copies" that get pushed to TFS?

Or, think the repositories available on GItHub. When you clone a repository, you are making a copy from that "master copy" to your PC (which then enters the development environment), but in which environment does that repository belong when it is in GitHub?

Upvotes: 0

Views: 187

Answers (1)

Mark Adelsberger
Mark Adelsberger

Reputation: 45659

I wouldn't normally describe a copy of the code in a state other than "deployed for execution" as being "in" this environment or that environment. I'm not saying it's necessarily wrong to describe it that way; just that it doesn't mean much and can be easily misinterpreted.

Now, deployed software - including software you deploy in support of your dev team - certainly does belong to an environment in every sense of the word. And every deployed instance that's used to do business[1] - even if it specifically helps your developers write software - is in a production environment. So if your servers are divided up by environment (which is for many reasons a very sensible thing to do), then you should have an instance of TFS on a production server (and therefore "in the production environment") to perform actual software development.

Now, if you're evaluating a tool, or writing extensions or plugins for it, or whatever, that's when you would put an instance of that tool in the dev and/or test environments. And again, a tool like TFS is no exception.

So I have my TFS server in my production environment, and I start writing code for MySuperWidget.dll; which I host in a repo within that TFS instance. Now I have a copy of the code, and that copy of code is written to disk on a production server (because that's where TFS is); so is that "code in production?" Not by any definition I call useful, because you aren't going to execute that particular code in production. If you call it "in production", you're implying that every check-in might need to follow your procedures for deploying to production. That is why I don't think of undeployed copies of code as being "in" any environment, even though certainly the disk they sit on is run by a server that is, itself, in some environment or other.

[1] : Perhaps I should say every server-deployed instance, because you might note that the software on a developer's machine - which you've defined as part of the development environment - is deployed for production by my definition. The local environment is typically considered a bit of an odd case. (Or, more often, it's just not considered in this way.)

Consider this: I've claimed that your live TFS server is a production server. Your workstation must be allowed to connect to it, so using typical rules for cross-environment connectivity, it would not be proper for your workstation to be considered a part of the dev environment.

Yet you must be able to deploy WIP versions of your software locally for debugging, so surely you can't consider the workstation exactly under the rules for the "production environment" either.

Upvotes: 2

Related Questions