A Tighter Integration
-
A Tighter IntegrationIn checking out the news about future Visual Studio releases, it's interesting to see Microsoft spending more time trying to build team oriented tools. I know that other suites of tools from companies have tackled this before, but since Microsoft dominates the tool market, it's important for some of these capabilities to be built into their tools. I'd like to see the price come down more, and I think it would end up generating more revenue for Microsoft overall.
This has some interesting implications for DBAs in that they should be able to work more closely with developers and also maintain more control over them. With workflow, testing, and all code, including T-SQL, assemblies, and schema captured in version control and worked on from within Visual Studio means that developers will be more likely to use the tool and have their work tracked rather than jumping over to Enterprise Manager/Management Studio and editing something on the fly.
The other thing I like about this system is that it forces the DBA to disclose their work to developers. It means developers can see how the DBA writes code and perhaps learn more about good querying habits. And it should mean that the deployment of changes can be better tracked.
I haven't really played with VSTS, though we're working on getting all our code in VSS and available to all of us here, but one thing I'd hope to see built in is a deployment process that uses specific accounts to make changes. Something that allows some control over making the changes.
It would be great if a single account could be used, maybe even the change manager, and all other rights, developers, DBAs not in production, etc. could be revoked so that everything had to come from Visual Studio.
Steve Jones
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com -
DataBase Administrator or DataBase Developer?
I believe that we will see more DataBase Developers emerge, using the new VS and Team tools for DataBases. Developers in the true since of the word, working in the research and coding departments, not QA or Production. Leaving the pure DataBase Administrators attending to Production matters of tuning the server and/or database, not changing code.
The tighter integration should cause us to treat the database more like any other managed code, allowing implementation to push the code up to QA and Production while relying on QA feedback to rework the database code for performance purposes.
in short, Progress ...
[font="Arial"]Clifton G. Collins III[/font]
-
The Wal-Mart approach to pricing (sell each for less in order to sell more and get more total dollars) works in most places that it is tried. As long as high demand drives the sales of the general item then price breaks can be an effective marketing strategy. Resistance against the monster ("I don't mind paying a bit more just to keep my dollars out of Bill's pocket.") will still provide enough of a feeding trough for third party providers.
Collaboration tools are a good thing. They can help drive down walls between departments. We have been using Visual Studio effectively. A senior developer starts a class and defines the methods and properties, including parameters, while another team member fills in the code behind. We do the same thing with the UI. I would love to see this extened to the data layer.
ATBCharles Kincaid
-
Just a couple of points, I'm already working as a Database Developer. I spend 90% of my time worrying about structural design and database coding. Backups, security, system settings, etc., are handled by a different set of DBA's.
With that, the new Visual Studio environment is marvelous. Well, it will be once it works right. At CTP4 they still don't have SQL 2005 functionality working, there are issues around how to configure security (that's looking to be a pain in the tucas) and some other issues. However, based on the work I've done with it so far, it probably will do exactly what Steve was asking of it. The ability to integrate the database builds directly with the code builds and control both from the TFS build process will, at some point, create huge changes in how we work.
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
-
'This has some interesting implications for DBAs in that they should be able to work more closely with developers and also maintain more control over them.'
I think this may be intended to say something a little different to what it actually says. In my experience - and I am a developer, not a DBA - it is the developers who are in control, and the DBA, if the company has one, is a tool to be used in developing the system. I supply the database specification and he simply produces it for me. And hopefully he keeps it simple, too!
-
It's great that the tools will support this. However that is not enough. The biggest paradigm change must occur in the organizations that use these tools and platforms. In other words it's all about "process". Without "process" you have nothing - or in any event the sameold environment you had before, just shinier.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
Sure, John. I not about to go up to most DBA's that I know and say, "You are a tool. How's it going, Tool?" Can't think of a quicker way to start something.
What was it "The Prisoner" said? "I am not a number! I am a free man!"
Just a bit of humor here.
ATBCharles Kincaid
-
Oh come on man... It'd be race. Can you get back to your desk faster than I can revoke your privileges. Could be entertaining.
Hey John: Lighten up Frances. Last time I looked, we were a team working to a common goal with the best interests of the company at heart, etc., etc. There's zero need for anything like a p***ing match between Dev's & DBA's. For that matter between Dev's & Sysadmins or DBA's & Help Desk.
Now, those business analysts on the other hand...
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
-
Right, Grant. No need for the P matches between any groups. We have them between developers. The company owner says someting about a ruler and measuring anatomy parts. We call him the Sea Gull anyway.
Even people in different groups can, and should, come together as all groups are part of the Enterprise team. ESOP's will teach you that lesson. Better sales and customer relations means better stock prices. (All ecconomists can just swallow my over simplification.)
ATBCharles Kincaid
A Tighter IntegrationViewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply