Replace Code of TFS project in a server from a different Server - tfs-2015

our team has migrated TFS projects to a new TFS server but few members of the team are committing code to old TFS server unknowingly. How do we migrate the code (Pull Requests, Branches)on the old TFS server and just replace the code part on the Target Server. Because, there are other items like user stories, TFS tickets valid on new server as users creating them.
Do we need to take down TFS server and will it affect other projects in collection.
I cannot find a straight forward way.

You can't find a straightforward way because there isn't one. The amount of effort that would be involved in re-synchronizing the two instances would be absolutely massive and would require the setup and usage of various third-party utilities.
Source code is easy enough to address on a person-by-person basis (have them update their remotes to point to the new server and push there instead). Pull requests? No way to migrate. Work items? Possible but a huge pain. Other stuff? Who knows.
Your best bet here is to cut your losses.

Related

Sonarqube DB Queries - How to find new issues?

I need to find all the issues discovered in a snapshot/scan in Sonarqube. I can't use the web API since the volume can be excessive for new projects on first scan. I have a query that can find the latest snapshot with the project information. I can query issues by project. I can't figure out how to relate issues to a snapshot. There has to be a way since Sonarqube does it - New issues on the Project page.
Has anyone done this or have enough experience with the crazy schema to be able to figure it out? Can't wait for the schema rationalization...
Sonarqube 5.6.3 on Windows 2012 R2 with SQL Server 2012.
There is currently no association between snapshot and issue. Nor has there ever been one. The closest you can come is to use date parameters to narrow the set of issues created right around the time of your analysis. Note that this could be difficult if you run analyses close together.
The "new issues" metrics shown on the project homepage are just that - metrics. However, if you click through on one, you'll find yourself in a date-based Issues search.
You can do the same sort of thing using the web service, again, via date-based criteria. Or you could use the sinceLeakPeriod parameter.

Track changes made to a database

Background:
I have a MS SQL Server database and I want to track changes to it. For example if a column needed to be added or removed or a table needed to be dropped. Something similar to Version control for regular code.
The problem:
While looking around I saw that there were some tools that can be used:
RedGate SQL Source Control
Visual Studio Database project
I am more interested in knowing if either of these tools will track changes to my database? More specifically I have a TFS server that is the source control for my MVC code, can I use either of these with TFS? Will it allow us to restore from older versions? Will it allow multiple developers to work on the database simultaneously?
For this type of work, ApexSQL Source Control shown to be all that you need. With this SSMS add-in you can work directly on a database, and all of your changes will be tracked in real time.
Yes, several developers can work in the same time on the same database. When one developer works on a one or several objects, other developers can see which those objects are, and until the first one does not finish changing the others cannot change that object, they will not be allowed to.
If by any case, object is changed wrong, previous version or any earlier version can be restored at any moment.
This add-in has all necessary options and features to allow the developers to work without losing time for checking changes made against object, since the add-in does that for them. And you can always see by whom, when and what that change is.
Being in the database version control space for 5 years (as director of product management at DBmaestro) and having worked as a DBA for over two decades, I can tell you the simple fact that you cannot treat the database objects as you treat your Java, C# or other files and save the changes in simple DDL scripts.
There are many reasons and I'll name a few:
Files are stored locally on the developer’s PC and the change s/he
makes do not affect other developers. Likewise, the developer is not
affected by changes made by her colleague. In database this is
(usually) not the case and developers share the same database
environment, so any change that were committed to the database affect
others.
Publishing code changes is done using the Check-In / Submit Changes /
etc. (depending on which source control tool you use). At that point,
the code from the local directory of the developer is inserted into
the source control repository. Developer who wants to get the latest
code need to request it from the source control tool. In database
the change already exists and impacts other data even if it was not
checked-in into the repository.
During the file check-in, the source control tool performs a conflict
check to see if the same file was modified and checked-in by another
developer during the time you modified your local copy. Again there
is no check for this in the database. If you alter a procedure from
your local PC and at the same time I modify the same procedure with
code form my local PC then we override each other’s changes.
The build process of code is done by getting the label / latest
version of the code to an empty directory and then perform a build –
compile. The output are binaries in which we copy & replace the
existing. We don't care what was before. In database we cannot
recreate the database as we need to maintain the data! Also the
deployment executes SQL scripts which were generated in the build
process.
When executing the SQL scripts (with the DDL, DCL, DML (for static
content) commands) you assume the current structure of the
environment match the structure when you create the scripts. If not,
then your scripts can fail as you are trying to add new column which
already exists.
Treating SQL scripts as code and manually generating them will cause
syntax errors, database dependencies errors, scripts that are not
reusable which complicate the task of developing, maintaining,
testing those scripts. In addition, those scripts may run on an
environment which is different from the one you though it would run
on.
Sometimes the script in the version control repository does not match
the structure of the object that was tested and then errors will
happen in production!
There are many more, but I think you got the picture.
What I found that works is the following:
Use an enforced version control system that enforces
check-out/check-in operations on the database objects. This will
make sure the version control repository matches the code that was
checked-in as it reads the metadata of the object in the check-in
operation and not as a separated step done manually. This also allow
several developers to work in parallel on the same database while
preventing them to accidently override each other code.
Use an impact analysis that utilize baselines as part of the
comparison to identify conflicts and identify if a change (when
comparing the object's structure between the source control
repository and the database) is a real change that origin from
development or a change that was origin from a different path and
then it should be skipped, such as different branch or an emergency
fix.
An article I wrote on this was published here, you are welcome to read it.
If you're looking for a product that will track changes into TFS from your SQL Server automatically, I'd invite you take a look at our product, Sql Historian. It's different from most other SQL version control systems (including the ones you've listed) in that it does not require developers to perform a check-in ritual to synchronize version control with what's already committed to the db.
However, features common with Sql Historian and the other two systems you mention are: working with TFS, the ability to view older versions of your db objects, and allowing multiple users on the db at the same time.

Removing "dead" user accounts from TFS & SQL after server migration

I have searched high and low for a solution to this problem to no avail.
Basically, the situation is as follows:
We are currently migrating our existing TFS server to another machine, which has been going well up until now.
Unfortunately i'm unable to complete the configuration of Report server and the likes as I get the following error:
"Failed to add SWSERVER\susan account to the TFSEXECROLE role on the Tfs_Warehouse relational database"
SWSERVER is the name of the previous machine that hosted the TFS server.
The thing is that SWSERVER\susan is an absolete account, and was actually removed as a user account on the previous machine, which I think is a major part of the problem.
From what I can gather is that TFS can still see it in the restored databases and thinks it's a viable account but seeing as the account technically doesn't exist it can't actually do anything with it.
Another part of the question is that if I go to the original (SWSERVER) and remove the SWSERVER\susan user, will that have an effect on how TFS or SQL operate especially if that account (or any other similar account) are linked to anything in either program?
I'd much appreciate any help anyone can provide.
I've hope i've explained my situation well enough but if anybody needs any more information, please don't hesitate to let me know.
You can't remove users, they will fall out of scope anyway, however that is not your problem. Your TFS instance has been moved from one server to another without following the documented procedure.
You need to follow the instruction to Move Team Foundation Server from one environment to another. Although they will be based on the more common move of Domain to Domain you can think of a non-domain joined server as having a domain of the same name as the local computer.
Now this documentation also follow as using the same hardware so you will need to mix and match between Move Team Foundation Server from one environment to another and Move Team Foundation Server from one hardware configuration to another.
While not really that hard you do need to follow all of the steps...
Just want to thank you for your reply and help. As it turns out I was flogging a dead horse with the TFS Reporting setups when I found out that the reports aren't even used currently on the existing setup.
I did however manage to figure out that if I added every user that previously existed as Windows users on the new machine and then used the TFSconfig Identities /change command to change the domain (machine name, in this case) name to that of the new server then I stopped getting the error messages and after 3-4 reinstall attempts all seems to be working the way it should.
This link was incredibly helpful:
http://msdn.microsoft.com/en-us/library/ms404883.aspx
Thanks again!

Offline database solution for sql server

Here's task: We have an sql server database. which is hosted at our server. What we need to do is: we need to create a non-techy-users interface (basically insert/edit forms) and let these non-techy-users to install this database locally, since they are located in the areas without internet connection. Then when they're done using the database we get the data from them and inster it in our database.
The biggest concern is that it is not trivial for non-it people to install sql server. Can you please advise me what solution should I choose? Simple Access should work fine, but i really do not want to mess with it and have data conversion back and forth between engines.
Sync Framework for SQL Server: your application uses a lite weight, embedded SQL Server CE (no installation, just a couple of DLLs deployed along with your app) and the sync framework manages the synchronization with the 'mother ship' SQL Server.
Out of interest, why do they need their own installation? Can't you create a new database on your existing instance?
If you're looking for an easy way to create insert/edit forms on your database, have you considered looking at Microsoft's new LightSwitch product (currently in Beta) or Microsoft's Dynamic Data?

Automatic incremental SQL Script generation for incremental, nightly builds when using Team Build in TFS 2008 and Visual Studio 2008?

hope that everybody here is OK.
We are using VS 2008 as development tool, TFS 2008 as version control as well as build automation. Some of our developer use dbpro for databases changes and some use SQL Server management studio.
I am trying to automate build for Web Application built using C# and VB.Net.
Our scenario is such that we have a central database to which our web application connects.
Whenever we supply our clients with a new functionality or a bug fix, we supply them incremental builds.
The SQL script is checked into source control for every incremental build when they have made and tested there changes on our central DB Server.
I want to generate Differential script that can be run at the client as an incremental update script. Now to come about it is a problem. Sometimes our developers tend to forget the database change-sets and the script in the source control is missing an SP or a two.
Also, sometimes we need to insert default data into some of the tables that have strict stringent values and not test values. Like a table that contains Services provided by the panel, we add a new service name, signature, credentials and service address, etc etc in the ServiceTable. Besides this many other tables may have test data that may not be needed.
If we use DataCompare, it will generate changeset for required data (important for client to enable certain services) and our test data that was added to the database as a result of our testing of the functionality or bug fix.
Currently i am using SQLSchemaCompareTask (from Visual Studio 2008 Team Database Professional Power Tools API) in the TFSBuild.proj file of the build definition for TFS 2008.
Using SQLSchemaCompareTask, the script generated contains database names like [dbo]. etc which are not desired as the script fails when run against SQL Server 2000 databses (Some of our client still use SQL Server 2000) databases as teh backend of the application.
Also default data can't be generated by this process.
To overcome this problem, i have to come up with a solution that can compare databases and generate script automatically that does not have to be manually reviewed again before being sent to the client.
Please suggest effective methodology of such SQL script generation and suggest whether two different databases may be used or something ? Is there any toolkit or api that can enable build automation for SQL Server databases?
Thank you all.
Regards
Steve
Try to use SQL Examiner Suite for this:
http://www.sqlaccessories.com/SQL_Examiner_Suite/
The tool compares both schema and data and produces synchronization scrips (or differentials scripts). You can automate script creation with supplied command-line tool.
Rather than collating many individual change set scripts (and therefore occasionally missing objects out), why not use schema compare and data compare to create a single script from your database project using a database equivalent to your client's on the target? This should create a script tailored to their requirements.
In data compare you can exclude test data records that you don't want pushed to your client by unchecking them in the lower grid.