I have two development environments, one for production and one for development. In TFS is there a way I can keep different versions of a file for each environment?
I would like to do this on my Web.config file where I keep different connection string for each environment. Right now I either have to keep that file checked out in both environments with there respective variables or update it every time I change environments.
In TFS you can do that using branching and merging... create one branch for production and one for deployment
Branching is a feature that allows a collection of files to evolve in two or more divergent paths. Branching is frequently used when teams have to maintain two or more similar code bases
Merging is the process of combining the changes in two distinct branches. A merge operation takes changes that have occurred in the source branch and integrates them into the target branch. Merging integrates all types of changes in the source branch including name changes, file edits, file additions, and file delete and undelete changes. If items have been modified in both the source and target branches, you will be prompted to resolve conflicts.
you can find more on branching and merging here
Related
Given a set of code that needs to behave slightly differently on varying production servers, you can create release configurations in asp.net with different symbols so that the compiler can compile the code under each release configuration in the desired manner. However, the web.config file for each of these production deployments might need to be identical or nearly identical. Even so, web.config will vary as you deploy to dev/QA/staging servers, which is why we have the feature of having a transforms based on combinations of publication profile (often used to distinguish between dev/QA/prod deployments) and release configuration.
How can I set up using the same base transform for all of my production publication profiles when I need multiple production publication profiles? In my above example, I need multiple production publication profiles because I need to deploy with different symbols for the compiler even though web.config might be identical or very similar. If I don't reuse, I end up with duplication of the production publication profile transforms across each of the different release configurations.
For example, suppose I am setting up a website to work differently if accessed within a network vs called from outside the network, and I'll use two separate web servers for that variance in the deployment of the website. Where before I had release configurations Debug and Release, I now have additionally Internal Debug and Internal Release. I have four release configuration transforms (Web.Debug.config, Web.Internal Debug.config, ...). For publication profiles, I have ProductionExternal and ProductionInternal. Everything up to this point seems ok. However, then I also have to create Web.ProductionExternal.config and Web.ProductionInternal.config which set up connections to databases and the like that are identical or perhaps nearly identical. I'd prefer to instead be able to say inside Web.ProductionInternal.config to use everything in Web.ProductionExternal.config plus XYZ modifications so that as I need to update, I only have one place to update.
This problem gets worse as you look across dev/QA deployments, or if there are more publication profiles that are similar.
https://www.codeproject.com/Questions/553960/Chainedplus-2fplusNestedplusWeb-configplusTransfor appears to be describing the same problem I'm facing, but never got an answer.
I have a question regarding working on Flyway with Git.
How to organize the work?
Two developers can create new SQL versions but on Git I think there should be one version of code to see all changes.
I mean when I am creating VBA code I am pushing to Git only one workbook and all changes there are updated when new version is pushed.
What about Flyway and creating multiple files?
How to do it?
Working with git usually implies working with different branches across developers.
As long as each developer is working on an individual branch you would not experience any problems with "seeing all changes" (from the perspective of such developer).
You will, however, experience problems in cases where those different developers are applying their (potentially different) flyway migrations to the very same database schema. In such case you may either drop the schema before applying flyway migrations or use a separate database instance per developer.
Now remember flyway is using migrations for expressing the sequence of changes that will form the final schema (or database content). migrations with flyway are just files (text files with sql code or java classes). For further details you might consult the flyway documentation
If you are looking at a single branch, e.g. as a result of merging various (remote) copies or other branches, you will encounter the following cases:
new migration (aka new file)
Such file will be added to the total set of migrations on the target branch. The main problem is ensuring (using a proper naming convention) that the new migration is executed at the proper place within the sequence of migrations.
modified existing migration (aka change to a file)
After a merge the modifications are part of the file and as such visible to the users of that branch.
deleted migration
Here the modification is becoming visible to the target branch immediately after the merge.
In any case (whether you are keeping the complete set of migrations as a single file (not recommended!) or as a set of files (possible distributed across various folders), there will be a exact version of what is the "current" state of the migrations for a given branch.
EDIT:
Consider the following example based on your additional information:
branch b1 has the following migrations:
03.02.12__creating table.sql
05.02.12__Altering table
branch b2 has:
- 04.02.12__Adding Column.
After merge of both branches into master branch you will ending with:
03.02.12__creating table.sql
04.02.12__Adding Column.
05.02.12__Altering table
Given the dates being the versions the list above gives the sequence of application of these migrations by flyway from the master branch (according to lexical ordering).
As there is no files with identical name with the git branches the files are just living side-by-side in the final version in the master branch.
We're running TFS 2015 and VS.NET 2015 for a large solution with an ASP.NET web app as the main project and several class library projects.
I'd like our team to start utilizing branches but the concept of branches being in separate folders is causing all sorts of issues with configuration.
Once the branch is completed the entire folder structure and web.config values, project references, reference paths etc are all now different, as the solution is being opened from a different folder than the main branch.
We use IIS virtual directories so that also doesn't work due to the new folder for the branch.
If I go ahead and make all of these manual changes to make our solution work from the new branch folder, then every time we do a forward integration from main->branch all of this config of course gets overwritten, and every developer on the team would need to redo this config
Surely there's a better method to handle branches for larger solutions which have a high level of config and customization, is there a way to keep a single physical folder and just specify which branch you want to work on?
Don't use long term branches. After moving from using long-term branches to a single main branch four all our teams I would never go back. The merges were always terrible, even for seemingly simple changes.
We now use Release Readiness analysis to allow multiple developers to work in parallel on different features. Check it out -
https://dotnetcatch.com/2016/02/16/are-you-release-ready/
I have a project (web), that interacts heavily with a service layer. The client has different staging servers for the deployment of the project and the service layer, like this:
Servers from A0..A9 for developement,
Servers from B0..B9 for data migration tests,
Servers from C0..C9 for integration test,
Servers from D0..D9 for QA,
Servers from E0..E9 for production
The WSDLs I'm consuming on the website to interact with the service layer, change from one group of server to the other.
How can I keep different versions of the WSDLs in the different branches using a git workflow with three branches (master, dev, qa)?
As you explained in your comment, the branches will be merged, and the WSDL files will conflict. When that happens, you have to resolve the conflict by keeping the right version of the WSDL file.
For example, if you are on qa, merging from dev, and there is a conflict on a WSDL file, you can resolve it with:
git checkout HEAD file.wsdl
This will restore the WSDL file as it was before the merge, and you can commit the merge.
However, if there are changes in the WSDL file but there are no conflicts, then git merge will automatically merge them. If that's not what you want, and you really want to preserve the file without merging, then you could merge like this:
git merge dev --no-commit --no-ff
git checkout HEAD file.wsdl
git commit
UPDATE
To make this easier, see the first answer to this other question:
Git: ignore some files during a merge (keep some files restricted to one branch)
It offers 3 different solutions, make sure to consider all of them.
I think branching is the wrong tool to use. Branches are highly useful for (more or less) independent development that needs that take place in parallel and in isolation. Your use case of multiple deployment environments doesn't appear to fit that model. It also doesn't scale very well if you need multiple branches for e.g. releases and always have to create and maintain the deployment-specific child branches.
You would probably be better served by a single branch that defines multiple configurations (either for deployment or building, depending on what consumes the WSDL file).
This assumes that the WSDL file is the only different between the branches, which is the impression I get from the question.
I have an ASP.NET project under git where we follow the convention of using a branch for a feature. We just started using SQL Server Data Tools to manage schema changes (quite new to it, so I suspect it may have features that get me to what I need).
I am looking for some strategies that have worked for other teams that manage switching between branches that have different DB schemas and then successfully merging branches together. Ideally, after merging all the features, I would have implicitly created a change script(s) to deploy for the release to production.
Note I am using SQL Server 2008 R2
There are multiple parts to this strategy. One aspect is the handling of the storage of the different branches, and what has worked well for my teams has been to use different SQL Server instances for each branch (rather than naming individual databases with branch-specific prefixes or suffixes, e.g., MyDatabase_FeatureBranchX, which can get out of hand). This enables the corresponding database(s) in each branch to have the same names (for clarity) but also allows for physical and logical isolation of a given branch's SQL resources (data files, access permissions, etc.).
As for the second, more interesting aspect (which I think is the main intent of your question), you might consider utilizing a code-based "migrations" approach -- e.g., using FluentMigrator or the like. Provided that you've got a standard baseline schema from which each branch was initially created, you can create the appropriate migrations in code as part of your feature development in each branch (and apply them to that branch's SQL instance). When it comes time to merge the branch into trunk, you'd also be merging and then applying that branch's migrations.
At best, this means that you could simply run the migration tool against your trunk instance after the merge, in order to apply all the branch's migrations, since tools like this automatically keep track of which migrations have been applied (via a custom database table) and do not reapply them. Provided that you're also doing periodic merges of your trunk code (including its migrations) into your feature branch throughout its development, and you're applying those migrations, you would also be ensuring that your feature branch's schema is being kept up to date, which minimizes the nasty surprises at merge time.
When it comes time to deploy your trunk to production, these same migrations would be applied once again. FluentMigrator offers various runners: a console application, NAnt, MSBuild, and Rake.
I would highly recommend using a timestamp-based (e.g., 201210241033) migration ID strategy, rather than simple sequential integers (1, 2, ...), to minimize the likelihood of collisions and changes being applied out of the intended sequence.