New answers tagged

2

Lots of people use version control with databases. There's more than one pattern for doing so and any number of tools but fundamentally its a sound way to go. Similarly I strongly advocate for local databases for developers if at all reasonable - you will get merge issues if you're changing the schema a lot, but you should be able to work out practices to ...


0

I had thought about a similar setup a few years ago. If you happen to use MS SQL Server, then Visual Studio and/or SQL Server Management Studio have some good tools to help with that. (Check out the database project in Visual Studio. It's made a lot of progress in recent years.) The only downside is the amount of work that needs to be done upfront, to build ...


4

We have a set of SQL scripts that we use to create and modify the DB between versions - as its text, its stored in the VCS and tagged along with all the other code. One of the scripts is a "set up default data" one, and another is a dev-specific script that sets all the usual environment, such as developer users. When you want a new DB, its trivial to run ...


0

First off, there are tools out there that can scan ports and network traffic to help you discover your software catalog but the bottom line is in order to be highly accurate you will have to touch every web-service or application and redeploy them to properly report their build versions and other information you want from them.. no matter what the salesman ...


0

Committing broken tests / broken code to your local repo is not problematic in and of itself. Problems start to arise when one locally commits to a specially-designated integration branch in anticipation of a push to a central repo. Real problems do arise when one pushes broken stuff to a specially-designated branch on a central repository. A system that ...


2

Running your automated tests on your CI Server is actually a form of Integration testing. When a developer runs tests locally they are validating whether the changes they have made mesh with the state of the entire system when they checked out their code. Your CI Server, on the other hand, is continually integrating work from all developers. When it runs ...


7

Usually the developer runs them manually before checking in, and a CI server runs them automatically after checking in. Programmers are usually pretty good about running unit tests for incremental builds on the configuration they've been working on, but they don't do things like do a clean build from a completely clean checkout from version control, run ...


1

I'm thinking you might want to pop this question over to Server Fault and turn it around: how do sysadmins for big corporations know what versions of what software is installed on their client machines. There might be some industry-standard solution that looks at, say, the version of DLL's in a predefined location on each machine that it works with. If ...


0

At some point, a full set of integration tests may take many hours to complete, even on expensive hardware. One of the options is not to run the majority of those tests on every commit, and instead run them every night, or in a continuous batch mode (once per multiple commits). This, however, creates a new problem - developers don't receive immediate ...


0

To let developers know that they broke something, you can use one of the build notification tools. TeamCity has a desktop notifier bundled with it. This app will show the status of selected builds in tray area at all times. There are also similar tools for other CI servers, like Catlight or CCMenu/CCTray.


3

I have currently my config files in the build process, however whenever i will have the opportunity i will externalize them. Here is a general answer : Because the client may need to change some parameters without having a new delivery. Let's say we use a database, and for a specific reason, the client wants to change the database to point to a new ...



Top 50 recent answers are included