Category: Continuous Deployment

Aug24201824 August 201824 August 20184 Commentsby Gregor Suttie

VSTS and Git Integration for Deploying to Azure – Part 3

Posted in Azure, Continuous Deployment, VSTS

In Part 3 I will cover how to create a Release off of a Build we create from Part 2 https://gregorsuttie.com/2018/08/24/vsts-and-git-integration-for-deploying-to-azure-part-2/

So to create a new Release we click the plus icon as shown below – nothing like consistency in the ui 😉

So again we get to choose a template this time for our Release Pipeline like so.

After I choose Azure app Service Deployment I get this screen.

Here I get to change the Environment name, so I edited Environment1 to be Development and then I need to select Add next to Artifacts to choose the deployment artifacts (the files i wish to deploy)

Here I am selecting the artifacts to deploy, I have chosen the Source Type as Build and the Build Pipeline both from part 2 and given the Release pipeline a name and then I click Add.

Now we can choose to setup release based on a number of things, we can make them manual or automated deployments based on triggers etc.

One example is a scheduled trigger and you can set this up by clicking Schedule release trigger as below.

With VSTS there are is a tonne of options to try out, its very easy to have either manual builds and manual releases and just as easy to have fully automated build, test deploy pipelines.

Aug24201824 August 201826 August 20183 Commentsby Gregor Suttie

VSTS and Git Integration for Deploying to Azure – Part 2

Posted in Azure, Best Practices, Continuous Deployment, VSTS

Ok so in this post (part 2) I promised to show you how to use Visual Studio Team Services (VSTS) to build, test and deploy your code to Azure.

Using Visual Studio 2017 with the git integration tools – Part 1 https://gregorsuttie.com/2018/08/24/vsts-and-git-integration-for-deploying-to-azure-part-1
Deploying to Azure using VSTS with a CI / CD pipeline – Part 3 https://gregorsuttie.com/2018/08/24/vsts-and-git-integration-for-deploying-to-azure-part-3/

Step 1 – Build your code using VSTS

Select Build and Release from inside VSTS like so

On the right hand side click where it says + New and you’ll see the next screen

I have rubbed out the names of the project I the above screen shot in case you’re wondering why it looks weird.

So here I’m saying that I want to use VSTS Git for where my source code belongs, I choose the Team Project, the Repository and which branch I am interested in building, then I select continue.

Now I need to select a template for the type of project I want to build like so.

I have chosen the Azure Web App for ASP.Net and then I click Apply.

On the next screen I need to choose

Name for the new Build
Which type of pool will I use to build the code
Locate the solution file for my project (from a selection)
I have chosen my Azure Subscription
And I have chosen the App service name from a drop down which comes from my Azure subscription.

Above you can see the list of steps which will be preformed

Use Nuget
Restore my Nuget Package(s)
Build the solution
Run any Tests within the solution
Attempt to Deploy the App Service (this step I would normally always remove)
Then VSTS publishes the artifacts to a Drop folder within VSTS which is later used in the Release part of VSTS to deploy the artifacts to Azure in tis case.

I will right click on step 5 and remove the App Service Deploy step as I just want to build my solution and create the deployment artifacts.

Ok so now you need to pay attention to this area of the build screen.

The red exclamation mark is showing us we need to fill out some further details before we can proceed, so lets fix this next.

So here we need to add a Branch Filter before it will allow us to Save the new Build.

And now we can either choose Save or Save and queue our new Build, I’ll select Save and queue.

And you’ll now see your Build queued.

One your build is there you more than likely want to setup continous integration, tick this checkbox inside Trigger.

In the screen above you click Enable Continous Integration and you can fill the screen below out

Join me in Part 3 – And I’ll walk-through deploying the code by creating a Release in VSTS for our new build artifacts.

Jan12201612 January 201612 January 20162 Commentsby Gregor Suttie

Continuous Deployments for SQL Server – Part 4

Posted in Continuous Deployment, Pro Tips, Productivity, RedGate, Tools

Ok so we have seen in parts 1, 2, and 3 how to go about adding your database to source control, as well as comparing the schema and the data held within our SQL Server databases.

Its time to go about releasing changes made from one database to another (again think of you deploying changes from UAT to Production). There are several ways to go about releasing the changes, here are two of them:-

Script the schema and data changes as 2 separate scripts, which you can easily combine yourself.
Use Redgate SQL Packager and even create an .exe to run which will allow us to update the database.

Ok so let me demo how to go about using option two using Redgate SQL Packager which comes with the Redgate SQL Toolbelt.

Start up SQL Packager and you’ll see this start-up screen:-

I want to package an upgrade to a database so I have selected that option already, the next screen shows this:-

Above I have chosen my Database server and the database I want to use as the source and the target database (one we want to update).

Below shows the database objects I wish to package and apply on the target database.

Below shows the tables whose data I want to package and apply to the new database.

Below shows me the script that has been generated for me, first tab is the schema script, second tab is the data script and the third tab is for any warnings.

And the last screen gives us a choice to either package the change as a .exe, package it as a c# project, launch the script in SQL Query Analyser or Save the script for further inspection.

Choose option 1, run the exe and your database updates are complete, that’s all there is to it, any issues found the changes will be rolled back as they are transactional, leaving your database in tact.

Once complete, just run SQL Compare and SQL Data Compare and you can verify all is good – and viola, you’ve just updated production with schema and database changes, and you’ve been given a few different ways to do using RedGate SQL Toolbelt.

Jan0420164 January 201612 January 20161 Commentby Gregor Suttie

Continuous Deployments for SQL Server – Part 3

Posted in Best Practices, Continuous Deployment, Pro Tips, RedGate, Tools

In part 2, I covered how to compare the schemas of two databases, in part 3 I’ll to cover how to compare the data held within these two databases, for that I am going to use SQL Data Compare.

Again we will use the same two databases, imagine your comparing UAT to Production and wish to compare the data within these two databases:-

(If the links are too small click on the image and then when the new window appears click on Original size at 1896 × 316)

The above image shows us that the t_depot database table has 4 rows which are in the Stock_DB_Deisgn table which aren’t within the STOCK_DB_DESIGN_ORIGINAL database. Again same as with SQL Compare, if we now click on Synchronization wizard we will see the following screen:-

And again as with SQL Compare, we get 2 options:-

Create a deployment script – use this option if you want to script the changes and review before running in the changes.
Synchronize Using SQL Data Compare – use this option if you want the tool to make the changes for you, you also get the option after its ran to automatically compare the 2 database data after the changes, to verify.

And that is it, easy, simple and straightforward, no manual steps involving creating scripts, no real chance for it to go wrong, plus once again you can source control the script if you really wanted to or share it with colleagues.

In part 4 I’ll cover how to deploy changes to your database whether its schema changes, data changes or both.

Jan0420164 January 201612 January 20162 Commentsby Gregor Suttie

Continuous Deployments for SQL Server – Part 2

Posted in Best Practices, Continuous Deployment, Pro Tips, Productivity, RedGate, Tools

If you’re using SQL server at work and manually deploying changes to your database using manually crafted scripts then its time to stop, there is a better way to do this by automating it, remove the chance of human error, this will also ensure that before you deploy to production that your changes will work, guaranteed.

In this blog post, I’ll discuss comparing two SQL Server databases which you can use SQL compare to funnily enough compare them and see the differences between the two, very quickly and reliably, imagine you wanted to compare your local Development database with say your Staging database for example, or compare UAT to Production.

In this blog post I’ll go over the steps I went through and how to use Sql Compare to work out what’s changed between the two databases, schema wise, then in the second part I will show you how to use SQL Data Compare. to compare the data within both databases and in part 3 I will either create a script to update the database or run an exe which the tools will create for us to make both databases the exact same, both in schema and in data, so let’s get started.

I’ve made dome schema changes to STOCK_DB_DESIGN and I wish to see whats changed, so lets see how to compare the 2 databases using SQL Compare (I’m using version 11).

In the screen shot above I’ve chosen my databases to compare and the tool will now run and show me what the schema differences between the two. the screen shot below shows the results after the tool has been ran against both databases.

On the left pane we see the changed database, on the right the database without these changes, I clicked on the first row to show the changes in the t_depot table and in the split at the bottom it shows the differences per object – very quick and easy to see what’s changed.

Update time
In order to update the older database with the new changes, we simply click on Deployment Wizard at the top and we get the following screen with options:-

Here we get 2 options:-

Create a deployment script – use this option if you want to script the changes and review before running in the changes.
Deploy Using SQL Compare – use this option if you want the tool to make the changes for you, you also get the option after its ran to automatically compare the 2 database after the changes to verify.

And that is it, easy, simple and straightforward, no manual steps involving creating scripts, no real chance for it to go wrong, plus you can source control the script if you really wanted to or share it with colleagues.

In part 3 I’ll cover comparing the 2 databases when it comes to data, for this we will use SQL Data Compare.

Jan0420164 January 201612 January 20161 Commentby Gregor Suttie

Continuous Deployments for SQL Server – Part 1

Posted in Best Practices, Continuous Deployment, Pro Tips, RedGate, Tools

Okay so your using a SQL Server database at work but you haven’t yet put the database into Source Control, here are some reasons as to why you want to do this:-

Source control your database
Trust me your going to want to do this if you haven’t already, it’s a good practice, it may save your skin some day, yes you can take backups which again is a good practice, here is an excellent article on why you want to do this:- Why put your database into source control?.

Okay now that we wish to put our database into source control – we still use Subversion at work so I downloaded Subversion and installed it locally as well as TortoiseSVN.
I have 2 databases called STOCK_DB_DESIGN and STOCK_DB_DESIGN_ORIGINAL within SQL Sever, the former had a few schema changes, imagine this is Development(STOCK_DB_DESIGN) and Staging(STOCK_DB_DESIGN_ORIGINAL).

I created a local repository within Subversion and downloaded RedGate’s Database Lifecycle Management Products.

This tool comes with SQL Compare and SQL Data compare as well as a host of other awesome SQL Server tools which you can find out about at the above link.

For this post I’ll be using Redgate’s SQL Source Control which adds a tab to SQL Server Management Studio and looks something like this:-

So lets go ahead and add a database to our source control using this tool, Select the option above, and then Next

I selected Subversion because at work we still use it, but you can use Git also and others, click Next

I then give it a repository URL, I already created a repository within Subversion for my database and added the URL like above, click Next and that’s it, our database is now linked to source control. Now to get the database scripts into Subversion we need to right click on the Database in question within SQL Server Management studio like so and select Commit Changes to source control:-

This will then add all of the database objects to SQL Source Control, once that’ completed, go into windows explorer and I use TortoiseSVN I can right click within my local SVN repository folder and then select Checkout or get latest version and this will result in the following folders being populated:-

And when I go into say the tables folder I’ll see the following:-

And that’s all there is to source controlling your SQL Server database. If I make change to an object say a table I’ll see whats changed locally in SQL Management Studio and I’ll know I still need to commit the change as seen below:-

In Part 2 I’ll show you how to compare schemas on both databases to work out what changes are required, and how to script them using the tool.

Jan0120161 January 20161 January 20160 Commentby Gregor Suttie

My todo list for work in 2016

Posted in Continuous Deployment, PowerShell, Pro Tips, Productivity, RedGate, Testing

Its 2016 and I like to make a list of things I wanna look into and put into place at work so here is a list of things I am aiming to do which also includes at my job in 2016:-

A blog post each week, last year I only managed 11 blog posts and that’s poor, so more blog posts will come in 2016.
Lightning Talks, we have started doing these at work and this year I plan to do a few of them if given the chance, I’m doing one on the 6th of January on as Developers Top 10 Best Practices which I will share about once I have done my talk.
Test 3rd party end points, have a dashboard page which tells us what is up and what is down, going to try to use the Chrome add-on called Postman and use collections within Postman to do this.
Database Deployments, currently we manually script everything and then get the dba to run the scripts in manually, we need to script the database and put it into Source control each release as a starting point, I’m looking forward to this as it well help aid with our deployments and speed them up. Hoping to get the RedGate Sql Toolbelt into the company so we can use this to help us achieve this.
Red/Green deployments, we currently deploy at weekends and this can and should change so that we aren’t spending time at weekends doing releases which take quite a lot of time, we can automate them more and this year I plan to fix that.
More Testing, we are closing in on unit testing our PowerShell scripts, this will be another nice addition to the number of different areas which we are currently testing which is great.
Code Reviews, need to figure out a way that keeps everyone from being bored, brings benefit to the team and keeps us developers on our toes going forward.
Continuous Improvement, test more, more in-depth code reviews, automate more, release finished work, tackle the back log each sprint.

That’s it for now, I will add to this lost throughout the year as we go, i will keep an eye on this post and how we get on and blog about each one individually, hopefully I’ll get the chance to work on some if not all of these this year.

Feel free to follow me on twitter at @gsuttie

Nov22201522 November 201522 November 20151 Commentby Gregor Suttie

Continous Deployment – Free Code Coverage tools Part 2

Posted in Continuous Deployment

ReportGenerator

Ok so after part 1 now we have code coverage results it would be nice to see a report of this so we can display this on our build server after our tests have run.

To do this we can use ReportGenerator which is also on Github and an executable.

This can also run be run locally or on the build server which is nice as its a pretty useful feature to see your code coverage after a build on your build server.

The nice part being we can drill into namespaces and see what’s covered and what’s not.

Now over time it would be great to see code coverage historical results and see the coverage going up, well ReportGenerator now does historical graphs which is just another type of chart which we can very easily have generated for us.

When I add the flag -historydir:SOME_DIRECTORY I can have the report keep a chart of coverage of a history of time/builds so we can see our code coverage going in the right direction over time which is what we are after.

In the above screen shot as I write tests which cover my code and do builds I can see a graph over time of the coverage going up which is exactly what we are after, add more code that’s uncovered and the graph will trend downwards which isn’t what we are after.

I hope this helps someone out there, feel free to get in touch with questions, best place to get me is on twitter @gsuttie

Fore more information about report generator check out the guy who wrote it https://github.com/danielpalme/ReportGenerator. Big thanks to Daniel Palme who you can reach out to on twitter @danielpalme.