Over the past few years, CI has come to be one of the best practices for software development. Indeed, it has numerous advantages: including high speed of product development, good code quality, enhanced communication between team members, and increased reliability of the process.
Essentially, Continuous Integration (CI) is a set of operating principles and practices that enable teams working on a project to deliver changes more frequently, exchange feedback on the changes, and get more reliable results.
It presupposes that developers push code to a shared repository a couple of times a day, which allows detecting errors at an early stage and locating them more quickly. The main reason for this is that it is a lot easier to identify defects and software quality issues on smaller code differentials rather than large chunks of code that have been developed over an extended period of time.
When you apply continuous testing, the small pieces of code can be tested just as they are integrated into the repository, which gives you the possibility to detect a problem before too long. One of the key points that the CI process encompasses is automation, which is a mechanism that will help integrate and validate the changes efficiently.
Therefore, we would like to show you some automation tools that will assist you in monitoring, simplify, and speed up various development operations. Let’s have a look at the following tools provided by Devart, which are involved in Continuous Integration both directly and indirectly. Ready, set, go!
dbForge Source Control
Although the dbForge Source Control tool is not used directly in the CI process, database developers utilize it quite intensively.
A database is a critical part of any application. If the changes to the database on the production side do not succeed during the delivery of the next upgrade to the customer, the entire application will not function. Therefore, the database during its development should be put under the version control of the Source Control tool in exactly the same way as developers version-control the application code.
When implementing a new feature or changing the current functionality, developers, in most cases, deploy a local database on their machines, make a number of necessary changes over database schema objects, such as add or change tables, columns, stored procedures, functions, etc. There can be loads of changes, and developers make them directly on a deployed database. Lastly, there comes a time to save changes to the database.
dbForge Source Control displays all the changes made and allows developers to look them through to make sure all the amendments are correct.
To gain a deeper understanding of dbForge Source Control usage in the CI process, see How dbForge Source Control is involved in the DevOps process. Additionally, you can watch the dbForge Source Control in the DevOps pipeline video.
dbForge Schema Compare
During Continuous Integration, the Devart SQL Compare tool called dbForge Schema Compare is usually involved in one of the first steps of the pipeline, namely in creating a database on a SQL Server.
As you know, a database can be developed from scratch, or it can be delivered to the customer, and its subsequent update will occur with the help of migration scripts. In both cases, you will initially need to deploy the database from the original state-based script. dbForge Schema Compare can be actively involved in creating the database in either case.
To get more information about how you can use dbForge Schema Compare in the CI process, see How dbForge Schema Compare
is involved in the DevOps process. Additionally, you can watch How to automate database schema changes for the CI process during database deployment.
dbForge Unit Test
Unit testing is the cornerstone of database CI, as it helps ensure that certain functionality works properly after various changes made by developers in the database project.
The dbForge Unit Test tool provides the ability to easily create, modify, and run tSQLt unit tests on a database.
To find out more about the dbForge Unit Test involvement in the CI process, see How dbForge Unit Test is involved in the DevOps process. Additionally, you can watch the Unit Testing for SQL Server Database in DevOps process video.
dbForge Data Generator
Using test data is one of the most important CI steps for databases.
Populating databases with test data plays an important role both at the stage of developing new tables and in the process of Continuous Integration. It is especially necessary to generate test data to emulate the update of the database to be delivered to the customer.
Data Generator allows you to produce not just dummy data, but quite realistic test data. Data such as personal names, street names, email addresses, phone numbers, bank codes, and much, much more can be easily generated.
To learn more about dbForge Data Generator and its involvement in the CI process, see How dbForge Data Generator is involved in the DevOps process. Additionally, you can watch Test data generation in the Continuous Integration and Deployment processes.
Data Pump
Apart from the need to populate the database with test data using such a powerful tool as dbForge Data Generator, you may encounter situations where it is required to fill the database with test data from different data files (csv, xml, json, ms excel, etc.). That’s when dbForge Data Pump comes into play, and the prerequisites for using it can be different.
Firstly, your testing team may prepare files that cover various boundary conditions, and you want to make sure that your functionality always works correctly on such data sets.
Secondly, after exporting from a real customer database you may obtain huge data files. The customer is willing to share this data with you to ensure that the upgrade will be successful namely on these data sets.
Thirdly, the customer may send you a file with a data set, also received after exporting from a real database. On this set, errors occur, and bugs come out. After fixing the bug, the developers want to include this specific data set into every CI process when testing on a persistent basis.
To discover more about the use of dbForge Data Pump in the CI process, follow the link. Additionally, you can watch How to import data to SQL Server database with dbForge Data Pump during the DevOps process.
SQL Complete
dbForge SQL Complete plays a supporting role in the CI process and serves for “cosmetic” purposes, providing the ability to format database creation scripts or update scripts before they get into the NuGet package.
When database development is in the hot phase, developers often tend to forget about formatting a script before sending the UPDATE scripts to source control (Git) or use different formatting tools with inconsistent settings. As a result, the script formatting in NuGet looks like a mess that has nothing to do with the corporate code formatting standards.
The dbForge SQL Complete tool helps avoid this situation and assists developers in ensuring that the update scripts will be sent to the NuGet package formatted in accordance with the standards.
To find out more about dbForge SQL Complete usage in the CI process, see How dbForge SQL Complete is involved in the DevOps process. additionally, you can watch the How dbForge SQL Complete is involved in the Database DevOps process video.
Conclusion
To sum up, in this article, we have considered several DevOps tools that will come in handy in a great many situations connected with database development, unit testing, data export and import, and data generation.
