I have a Dev and a Main branch of a project. They are staged at different URLs and I hold a reference to this URL in my project in a static class:
public static class Constants
{
public const string Url = "http://staging.myurl.com";
}
Now the URL will be different in each branch, but I don't want the URLs overwriting each-other whenever I merge Dev->Main, or Main->Dev.
Is there a way of telling TFS that I don't want the line to be merged, or must this be done at file level instead?
Does anyone have any suggestions of how I can maintain independent URLs in each branch? I don't want to use a database or a config file if I can help it. Is there a simple mechanism to facilitate this in TFS?
I have thought about wrapping the line in a pre-compile #if statement and checking for a specific build configuration, but I'm curious to know if there is a better way?
As it stands, you're hard-coding infrastructure concerns directly into your application, which is bad. Your application code should be environment-agnostic.
This should be managed via a configuration file; it's one of the canonical use-cases for it. The configuration file can either be transformed into an environment-specific version at build time (via web.config transforms), or ideally, at the time of deployment, via your deployment scripts.
There's no way to ignore specific lines. You can ignore specific files (via .tfignore for TFVC, or via .gitignore for Git), but you can't just tell version control to not version control a specific line of a file.
Related
I am trying to figure out if there is a difference between the two pre-defined variables in TFS Online 2017: $(Build.Repository.LocalPath) and $(Build.SourcesDirectory). I have a build that uses these two variables and didn't know if I could use them interchangeably or not.
Looking at Microsoft's documentation the descriptions are as follows:
$(Build.SourcesDirectory): The local path on the agent where your source code files are downloaded. For example: c:\agent_work\1\s
By default, new build definitions update only the changed files. You can modify how files are downloaded on the Repository tab.
$(Build.Repository.LocalPath): The local path on the agent where your source code files are downloaded. For example: c:\agent_work\1\s
By default, new build definitions update only the changed files. You can modify how files are downloaded on the Repository tab.
Are these representing the same thing or am I missing something?
They're synonyms. Most standard templates and tasks use the $(Build.SourcesDirectory), so that is what I tend to use.
They often result in the same but not necessarily. As described in the docs:
If you check out multiple repositories, the behavior is as follows (and might differ from the value of the Build.SourcesDirectory variable):
The description for Build.SourcesDirectory on the same page contains a similar note.
Basically if you want to define a custom path for the self checkout and still not need to specify the extra dir, you specifically need Build.Repository.LocalPath.
For clarity, you can still use Build.SourcesDirectory to resolve to the full path if you have the usual
- checkout: self
path: s
and I'd recommend using it whenever possible if so. If you have something like
- checkout: self
path: main_project
then you'd need $(Agent.BuildDirectory)/main_project to reach the same.
I asked the following two questions in JIRA Answers, but got no reply so far:
Question 1
Question 2
Basically my question is what's the best way to make changes in a JIRA production environment.
This will be rather general answer, but this is how I do it:
I avoid modifying JIRA production files. When I need it (e.g. mail templates), I keep them under source control along with plugin in 'deploy' directory which mimics JIRA directory structure so it is possible to grap it and deploy it with copy&paste
I frequently use javascript to decorate screens with custom behavior
Schema changes, custom fields and other meta data are all created in code
Keep everything in plugin and leverage plugin versioning system. Plugin should be able to check whether there is everything it needs and when not it should be able to upgrade incrementally.
For JIRA configuration - this is the same, plugin should check whether it has everything it needs, but you can also keep configuration changes in some excel file and have it under source control
My aproach is to have everything possible in source control and modify production files only when absolutely necessary. Do as much in code as possible.
I'm building a group of projects from the SVN. There is a possibility of changing the SVN location time to time. As there are bunch of projects I hope to give the repository url with a environment variable so i can change all the url's easily. Any idea how to do that??
In Subversion Source Code Management, you can use variable in the Repository URL, simply type:
http://my.svn.com/path/to/${VARIABLE}
${VARIABLE} is a job parameters that is defined earlier. Never heard of anyone wanting to use actual environment variables for this, but you can try with the same syntax.
By default, it will give you a red warning that this is not a valid URL. You can disable this warning by going to Manage Jenkins -> Configure System and look for Validate repository URLs up to the first variable name. Put a checkmark there and save.
How does ASP.NET MVC, if at all, deal with or provide ways to create your application using multiple environments? For example:
Development environment (local machine, probably run via the built-in web server and talking to a local database)
Testing (runs against a preloaded databse with example data, although this part could be skipped and mocks could be used)
Production database on a real server with real data
Ruby on Rails has the concept of environments and "automagically" can deduce if you're in development or production, so you can specify your connection information (connection string) in a config file and the framework dynamically pulls the appropriate one. Is there a similar way of doing things with .NET MVC? If not then how are professional developers using .NET MVC handling different environments?
The only way I can think of is to manually add an "environment" global method (or use an enum, or something like that, maybe this is a use for something like the State pattern?) and store the different connection strings in the web.config file, and then create a base class which all data access classes derive from which provides a way to obtain the connection string for the current environment; this would then have to be set to production when the time comes to put the application live.
Is there another way? Most of the .NET MVC videos and articles I've seen don't even bother with separate environments but only use a development database and don't indicate how you do it in production.
I'd say this is really a question of your company's internal processes. Since every company is a little bit different it's hard to have a "right" generic way to support dev/test/alpha/production and/or other environments.
One way: Create a setup program that supplies the correct connection string based on the environment chosen during the setup process.
Another way: System Admin edits web.config file to supply correct connection string during install.
Yet ANother Way: Connection strings are stored in the system registry.
Even Another Odd Way: You have all your connection strings for all environments in web.config, then a setting in appSettings the tells you which one to use.
Depending on the client, I've done all of these. There are more but these are the more popular.
(One client wanted to store the connecting string in the data base itself. Really.)
You can use alias for your database. You just point these aliases to different servers in the different environments. Stored in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\Connect if i remember right. Then you use the alias in the connectionstring.
In response to Jason's response:
We use Enterprise Library Environments to configure the different environment paramters and via msbuild invoke the Merge Configuration Tool that generates the different configs for each environment. The deploy process picks the right config file depending on which environment to install.
I was able to solve a similar situation following these steps:
In your Visual Studio, access Build > Configuration Manager
Click in "new"
Choose a name for your configuration, and then copy settings from an existing config. After the configuration creation, it will be available for you to target as build configuration
Create a Web.{env-name-you-chose}.config in your application folder, along with the original Web.config file.
Open your .csproj file with Visual Studio or any text editor
Search for a section that looks like the following and add the highlighted lines, with the config file name you gave previously:
Open your Visual Studio, reload projects if it's required, and now you are able to choose your configuration via CLI or manual publish using Visual Studio.
There is a Publishing Wizard (in Visual Studio) wich let's you change parts of web.config for release build automaticaly. Wich happens to be the feature you are asking about. No magic thou.
What we have done is during our automated build process (Hudson), we alter values in web.config depending on which environment the build is for. Unfortunately there isn't a magical way to do this.
For deployment, which I assume that is what the op was asking about, one creates multiple configurations and in the publish, picks a different configuration. These are called transforms and they operate on the web.config. One would have at least three publish profiles, one for dev, test and prod. One can change more than just the connection string in this way. One can turn on custom errors, turn off debugging and change values of configuration variables. I highly recommend it.
I have a similar question. I have a log table reader. I want it to read log tables in the development, test and production databases. The major difficulty lies in my user account doesn't have permission to look at test and production. It's some silly security thing. The user that I'm impersonating in the application does have permission. I'm struggling trying to tell MVC to build the test and production models using the impersonated user.
I'm looking for a way to edit a configuration file (web.config in an asp.net project) in a Team Build.
Specifically I'm looking at either uncommenting or adding identiy impersonate in the config file before copying the built web application to its destination.
I know that it's possible to have multiple config files and copy one over the other (we're using this approach to have different configurations for development, production, demo, etc), but in this case it would be nice to keep the configuration in a single file since the only change here is whether or not identity impersonate should be false or true.
I've been googling for a while now without finding any solution to this, but maybe there are someone here which could either help me figure out how or simply state that it's not possible. Any ideas?
Have a look at http://www.codeplex.com/sdctasks
It's a set of build tasks which allow you to do all sorts of fun things. There are several tasks which are web(site) related, but if it comes to it, there are XML tasks too which should allow you to manipulate the file appropriately
The XmlPoke msbuild 4.0 task will help you, and this is buit in. Here's the link: http://msdn.microsoft.com/en-us/library/ff598687.aspx