We are a team which consists of Microsoft SQL Server DBAs, Consultants and Business Analysts and we have been developing a deployment tool, TransSQL for Microsoft SQL Server.
We have had many motivations to prepare a tool like this especially to make our peers' lives easier. This tools is especially considered for System Administrators and Microsoft SQL Server DBAs.
Nowadays we are so busy with the development and function tests of TransSQL, so we will be building our official web site later. As we are so exited about this tool, we wanted to share some news and details about it with you before its release and the website.
Please be informed that the screen images that are shown below can be changed later as the development continues.
Let me tell you just a little bit about how TransSQL can help you with your Microsoft SQL Server environments:
Problem 1: A lot of companies are working for government agencies, banks, hospitals financial companies etc. whose data is so critical and most of these establishments have their regulations and audits. They want other companies that they are working with to align with some security and other measures. Because of the cooperations between these establishments and your company, you will have to store their critical data in your own database servers. Because of the sensitivity and severity of this kind of data these establishments do not want your IT personnel to modify or see this data directly, freely and without any control.
 |
| Packages are created for applications and every application has its environments. These details are defined in the Application Management tab. |
 |
| When users select List type from the Types, they can run SELECT statements against the source and target databases. This feature can be turned on or off from the Settings tab by the admin. Also, the result set can be limited by some certain number by the admin again as it can be seen from this screen image, it's limited by 150 records. |
Problem 2: A lot of application developers are not aware of the database development best practices although some of their job is to develop database applications. Especially for these developers it's kind of dangerous to let them deploy SQL codes to the production servers without any code review by a database administrator.
Solution 2: To deploy SQL codes using TransSQL, developers create packages. The packages consist of steps and steps are the SQL statements themselves. After the packages are created by the developers, TransSQL's administrators are informed by an email (optional) about the new packages. Administrators can execute or reject packages after reviewing them. So, all codes will be audited by the authorised personnel.
 |
| Package review. At the main window you see the packages that are created by the developers and at the front, you can see how code review is done. |
 |
| For instance if a Stored Procedure to be deployed does already exist at the target database, then it is shown to the administrator who reviews the package, for comparison. |
Problem 3: When developers directly connect to the production servers and perform modifications, nobody knows what has been done when and by whom.
Solution 3: TransSQL records every deployment. You can easily find who, when created a package and when it was deployed by whom or why it was rejected and if the package failed, what was the reason for that?
 |
| You can find every deployment details easily using versatile reporting. There are lots of criteria that you can add to find what you are looking for. |
Problem 4: Developers do not tend to document what they do. So for example in a typical environment when a code is deployed by a developer directly to the production servers and when that deployment causes performance or functional problems, nobody knows what has been changed.
Solution 4: Before deployments, TransSQL performs a backup for your Stored Procedures, Views, Functions, Triggers if they already exist at the target databases. So you can restore your problematic objects to their previous versions using these backups with some mouse clicks.
These are just some of the advantages of using TransSQL for your Microsoft SQL Server deployments.
How it works?
- You define an application in the "Application management" tab. Here, you make up name for your database application, select an environment relation, choose source Microsoft SQL Server Instance and database names, choose target Microsoft SQL Server Instance and database names and version of the application if applies.
- Then you can start creating packages to deploy your codes from source X to target Y. The packages are created in the "Package entry" tab. You can add DML / DDL statements to your package. Packages are consists of steps. You can assume steps as batches. A step can be a CREATE PROCEDURE script, or DELETE table SET field1 WHERE field2 = xxx script and it can also be an Export step.
- After editing your package you save it and then administrators see your package on the Package execution tab. They are also informed (optional) by email about your new packages. And you are informed (optional) by email about the execution of your packages.
That's it! It takes only a few minutes to learn how to use TransSQL. There are several permissions to use TransSQL. For instance you may want some of users to be able to create packages only and some of them can view the created packages only... Only some of them can be authorised to execute packages.
TransSQL is written in Turkish and English languages. The user interface language changes according to your Microsoft Windows OS Language settings.
Please feel free to make your comments, share your thoughts and suggestions to make TransSQL a better product to help you at your daily routine.
I will be sharing more details about the concepts and features of TransSQL. I will also record a video to introduce you to TransSQL.
Thanks for your time!
Ekrem Onsoy
