>> Right. Hey folks,
welcome to my session.
My name is Dmitry Lyalin.
I'm a Product Manager for Visual Studio Team Services.
And today, I'm going to talk to you about how to use
Visual Studio Team Services and
our Cloud-hosted build agents
to build your app in a Cloud.
We've also got Unity Team integration
that I want to show you as well which is really great.
So, I'm going to jump right
into it and get into the details.
So, first of all, what is Visual Studio Team Services?
A lot of people hear the word Visual Studio.
They assume this is a product that is focused on the IDE,
the Visual Studio product itself.
But actually, this is a cloud-hosted DevUp solution.
It has five major product areas
that I'm going to talk to you about today.
And we're going to demo only a few of them.
So, as a high level overview,
our product supports Agile Planning.
We have Kanban boards.
We have task management in the Cloud for you.
We have the ability to do
source control across Git & TFVC,
Git being the very popular one.
Industry standard implementation,
that will be part of my demo today.
We also have CI/CD pipelines that
enable you to do everything from
continuously integrate with your source code
as you're doing commits
all the way out for the release of your product to
a Cloud such as Azure or even AWS.
So, we've got great for an end to end
integration story there all
the way from planning through code.
We also have other capabilities.
We have things like package management.
We have things like load testing,
automated testing, unit testing,
lots of things that you can do.
We won't be able to cover all of that today.
Today, we're really going to be focused on
the build engine and Git source control.
So, let's go ahead and take a look at those things.
I closed at to say that as
a high level concept, VSTS is very open.
We have a marketplace. We inherently support
things like GiHub,Git itself, Docker.
We have great compatibility across all the platforms.
We have hosted build agents from Mac,
Linux, and Windows up in the Cloud.
And we're pretty freaking cheap,
we're basically free for people
that have teams that are five or less.
We have free built agents.
We have unlimited private Git repos, lots of great stuff.
So, that's the page and
visualstudio.com/vsts is where you can learn more.
But let's jump into the core of this presentation.
So today, I'm going to do three demos.
I'm going to, first of all, go through
the scenario of building
a Unity application up in a Cloud.
So with Unity, Unity
has their own service called Unity Teams.
And they have a built capability inside of that service.
And we will show you how to integrate
between our source control
and their service and
make it all work as a CI integration.
So, you'll be able to commit code in
VSTS and you'll go all the way out to their build
and automatically trigger a build in
their system allowing you to see if
everything is ready to be distributed.
We're going to do a second demo.
This demo is going to focus MonoGame.
MonoGame is something that we can
build inherently inside of our Cloud-hosted agents.
We have Windows agents for example.
They can build the Windows Native or
either VP app or even the Android app.
So, it works really well. And we can
do all of that without ever leaving VSTS.
So, I'll be able to demonstrate
this right in our product.
And then I'm going to end the demonstration by talking
about how you can do builds of your back-end services.
Doesn't matter if your service is
written .NET or Node or Python or Ruby.
That's really agnostic.
All the components will work.
You'll be able to plan against it.
You'll be able to store the source code for it.
You'll be able to trigger the builds for it.
And if you wanted to
do the release stuff we're not going to demo that.
I will also show as part of that experience the
pull request mechanism we have built in.
Because one of the things that we
find in real dev teams is
that you don't want people just checking
into master without having some review cycle.
So, we have a great interface for pull request,
other folks like GitHub have also
implemented interfaces on
pull request, but we have our own.
And it's forced by policy. That's really cool.
So, I'm going to demonstrate that towards the end.
So, let's go ahead and jump into the very first demo.
This is all the slides
I'm going to torture you with today.
So, the first demo, we're going to close iTunes.
We are definitely going to do that first.
That's what happens when you hook up your phone
to not die during the presentation.
All right. So, we're going to start off in VSTS itself.
So, let me put this up to full screen, and show you VSTS.
This is running in the Web browser.
So, we've got VSTS as a fully Cloud host solution.
You don't have to install anything.
I want to tell you how I got here, right?
I created my account. I've logged in.
I have all my code. Everything committed
and I set up a dashboard.
And that's what you're looking at here.
So, this is how most users of your team will
log in to take a look at what's going
on with the work assigned to them.
You can visualize the work on the dashboard.
You can see what's going on with the builds.
You can see how much work-based
and state you have assigned.
You can create arbitrary markdown sections
for putting like useful resources.
You can see other team members.
It's a fully customizable dashboard.
And I just want to show that as
an entry point because this
is a real way for you to set up
your team and get a sense of everything
that's going on inside of your repository,
inside of your build, inside of your releases.
Anything that's hosted within our product,
you can visualize on this dashboard
and even customize it yourself.
So, that's kind of a quick view.
And also, to show that this is interactive.
So, if I wanted to see something about a build,
the particular build that's exceeded or even worst,
failed, I can actually click on that and it's not static.
It'll actually take me to the field
build loaded up and I can see what went wrong there.
In this case, I know what went wrong.
So, I don't have to figure that out,
but I just wanted to show that dashboard
is quite a useful thing. All right.
So, let's talk about the abilities
within the Git's eco system we have built out.
Under "Code", you can see everything that is related to
all the repositories no matter
what type of repository they are that
are stored inside a VSTS, inside of your team.
So, this is limited to the scope of your team.
So, in my team, I have the following repositories,
I have a while in games
repository even if this is all just a fake demonstration.
So, that's where I keep my back-end service.
I have a Toy Nightmare which is a Unity sample game.
And I have Chomp which is a Mono sample game.
So, I have three different repos,
these have three different purposes.
And I will go ahead
and jump into the Toy Nightmare 1 right now.
So, Toy Nightmare is a Unity game
and its source code
is what you would expect for a Unity project.
You can basically visualize
it right here. You can go through it.
You can look at the assets.
You can go down to as a script UI and
we have visualization for things like
C Sharp with colors and everything.
So, you can really see your source code.
But you can even do things like view history.
So, you can see how we got here,
which commits caused that.
And if there was a definer,
you would even see a file compare view,
maybe I'll find a file later
to show you what that looks like.
I'm going to bring my UI back so I can head back.
So, that's really cool.
And you also have things like
search that's built right into our product.
So, let's say in this case,
we have a class called friends item render.
But lets say I was all the way back up here, right?
I'm like, I know the class
I am looking for, I need to find it.
We've built in things like,
I'm going to zoom in a little bit,
the code search that lets you filter based on
these different kind of classifiers
here and find what you need to do.
So, if I say ''Class.''
So, I'm going to do that right now. I'm going to say
''Class'' and put the class name, hit "Enter".
It's going to go ahead and find
everywhere where it can find that class.
And it's more than enough to actually find
a class and not a string with that name in it.
So, it's actually quite advanced
for anything that's built in C Sharp or .NET.
So, those are just some cool things that we
have inside of here for rendering the source code,
for viewing the source code,
for searching the source code.
But we also help you out with things like
the commits that are coming in and looking
at the branches that were used to get here.
So, if you look at the commits, we can see
the history of this project.
And if you're importing
the repository from GitHub or some other place,
it'll take your history with you.
So, it works just like you would expect Git to work.
And you have really rich ability
to go into any of the commands,
see which files are part of it,
and see who did it.
If I find one here's one with some differences, right?
So, you have a left right compare right
here, right in the Cloud.
So, it's really powerful UI for that.
And then under "Branches",
we have a list of
every branch both limited to like yours or all.
If you had more than one branch,
you would see all the branches here.
So again, very powerful Web UI that
allows you to explore this quite a bit.
Now, this is like a set of Unity game.
So, I'm going to go to Visual Studio right now.
And I'm going to open up, or actually,
I'm going to say I'm going to go to Unity,
because I want to go through
the way you would normally work.
So, here's my sample game.
Certainly didn't make it.
This is a sample from
the Unity side that we've
modified for a few things that we wanted to show.
Really Unity game, the one that we've
seen a million times if you ever looked at
the samples that Unity provides.
So, that's not really important.
What is important is showing you
some integration we have back up to our DevUp service.
So, I'm going to go ahead and open the source code.
And I'm going to make a change to this.
So, let's give it a second here.
It's going to log the settings.
And just like you would expect, Visual Studio starts,
figures out which files to load,
which projects that are connected to Unity game.
All right. So, there they are.
And what I'm going to do is I'm
going to change one of the files.
So, it doesn't matter which one, right?
So, let's pick one random one here.
And I'm really not going to make a big change.
Not a big change, right?
I'm not here to show you game programming,
just the back and
nature of it for us from the DevOps perspective.
So, I've made that change and
I'm going to show you use command line.
Let's do that to commit to change out.
So, I'm going to my Git command prompt.
I'm going to go to Toy Nightmare,
I'm going to do a Git status.
All right, a second,
make sure that I'm committing to the right place.
Yeah. Let's use the UI. All right.
So, I'm going to use the UI to just
do the command same thing.
No real difference here. So, I'm not put a great comment.
It saved the Commit. And I'm
going to sink that change up to the repo.
All right. That should be done any
second, write all the changes that committed.
So now, let's go back to VSTS
and take a look at that commit.
So, I'm going to go to my list of commits.
And as you can see, just now,
there was a commit but with a really terrible comment.
And you can see exactly what was changed.
But here's the cool thing, we've integrated this one.
By integrated, I use that word very lightly.
We basically connected it to Unity team build.
So, Unity has their own product,
it has nothing to do with Microsoft.
We didn't build it, we didn't enable anything special but
they themselves have enabled this experience to happen.
I'm just demonstrating how we configure to do so.
So, I'm going to open up in Unity, Teams, the project,
then I'm going to go straight to "Builds" because it's
the only thing I use
in there. I'm going to go to "Configure".
And I'm going to show you that I've configured
it to be watching my Repo in VSTS.
So, over an SSH key that I've
configured inside of VSTS which is really easy to do.
Well documented. I've configured it out to
my Repo and I've sold it to build 64-bit,
and 32-bit versions of this game.
And Unity can certainly do that.
So, it has in here,
if I open up "show basic",
I'll zoom in over here a little bit.
So, it has this auto build option and it's basically
watching for any changes inside of the source folder,
where you'd expect it
to look and just build out the game.
Now this can take up to seven minutes to trigger.
When I was practicing right before,
it actually triggered right away,
which I found really funny because it never does that,
but here it is it has triggered before plenty of times.
It really is building the game,
you can download and run it.
So, you can have a true CI integration between
the planning and the source code management
that you're doing inside of VSTS,
and it will flow very nicely into
the build agent that Unity has provided.
Unfortunately, the Unity engine
is going to cost you some money.
They require you to pay.
We are pretty much free for this scenario.
As one user, I don't have to pay for the VSTS up to five.
It is free for everybody.
So, that's simple. All right.
So that's kind of a quick demonstration of
how we've configured it all to work,
and I'll come back here later if I don't
forget and show you this thing,
really the trigger based on our commit,
of this really really non-important change,
and hopefully it won't break anything.
All right.
So, that was demo number one,
let's go to demo number two.
So number two, for this demo,
we're going to go back to MonoGames. We have a MonoGame.
Let me actually show you the MonoGame real quick.
Just to show you, that is a real sample.
Again, not a real game but a real enough sample.
So, this is a project that buddy of mine
created a while back, another Microsoft employee.
The game is called -. It's a Monster game.
It's called "Chomp" it has a couple of names to it.
But basically, it's a simple MonoGame.
It has a shared project, which has a bunch of code.
And then, it can be built out
to Windows Universal and Android.
And all of this is
buildable inside of our hosted build agents.
So in this case, we don't need the Unity Build Cloud,
because MonoGames, is all on .NET, and Xamarin,
and we can build all of that inside of VSTS.
So, I'm going to go ahead and
show you that inside of VSTS now.
I'm going to go in here.
And again, this dropdown,
on the top left, lets me switch Repos anytime I want.
So, I'm going to go ahead and switch to the Chomp repo,
and show you that we have again lots of history,
lots of code, that's where we checked in.
And specifically, we have a build,
defined inside of VSTS that's going to
trigger if I commit any changes to this Repo.
So, I'm going to go to build definitions,
and inside of the build definitions,
I basically use the out-of-the-box template.
So VSTS, let me explain this a little bit.
It's a task-based build system.
So you can come in here and you can
basically hit "New" and you have pre-selected templates,
and you can use those to get started.
I'll show you the one that actually works
from MonoGame almost out-of-the-box,
but you can also completely customize it and
I'll explain exactly how much in a second here.
So, let's hit "New" just to
demonstrate how much power this thing has.
It supports out-of-the-box, not
only our source control but also a GitHub,
GitHub Enterprise, Subversion, Bitbucket,
and even any externally hosted address,
something that you can hit over the
Internet and get Repo.
In this case, let's say I wanted to use ours,
I can select the repository that I'm targeting.
I'm not actually going to save this but
I'm going to demonstrate a few things through
this quick example just
to show you this experience of templates.
So, because MonoGame is
basically a .NET desktop application
as a starting point at least,
that's the way to think about it.
I use that when I was building my build definition.
And it almost perfectly configured it for that scenario.
So, this is what I mean by task-based system.
On the left here by default,
because I chose a template,
there's a bunch of tasks. And the tasks are movable.
You can literally drag them around.
You can go ahead and click on any one of them
and there's all sorts of
settings that you can change to them.
You can build your own tasks.
You can even build them and
publish them to the marketplace.
We have a lot of tasks that
we've built into the product ourselves.
So, we have things like everything, from .NET Core tasks,
all the way to uploading to FTP,
Google Play capability integration,
we have installed SSH Keys.
You can run Jenkins queries. There's so much here.
I mean, I literally don't know everything that's in here.
There's literally so many things that are available.
And on top of that, we have a marketplace.
So, the marketplace's where
our partners can publish anything they want.
In fact, either of us publishes
a first class extension for our product.
It's something they maintain.
I know Google's working in theirs as well.
And we fully support Azure out of the box.
So, you're not limited to which
Cloud you want to use with our system.
You are limited to what you want to build,
but our build system is really flexible.
We use VSTS to
build everything inside of Microsoft pretty much.
So, you have things like Minecraft for example, right?
They build on top of this thing,
just one example of some that they use are Build Engines.
And the way that we have it configured is that you
have the ability to set up
a trigger for continuous integration,
and that's how we're able
to commit a build which I'm going to do
in a second here based on each changes that are
happening to the Chomp game.
So, I'm going to go back to VS for a second here.
I'm going to go back to this Monster game.
Again, I'm going to make a really insignificant change
just to demonstrate the CI nature of it.
So, we're going to remove one letter here, nothing crazy.
And we're going to push these
changes after committing them.
So, we're going to go to changes real quick.
Small change.
I'm breaking all the rules of
proper source code management here but it's okay.
And I'm going to push these changes up.
All right, changes have gone up,
and if I did not mess anything up,
that should trigger our builds.
So, we're going to go to Builds.
Yes, I'm going to leave, because this was
just a demonstration, I don't care to save that.
And there you go.
It's actually working, it's in progress.
So, my MonoGame native build is in progress,
and I can click right here to
see what's exactly happening in there.
So, I'm going to do that and show you
the rich nature of the information that we expose to you.
Kind of again, I forget if I said this or not,
but we have Windows,
Linux, and Mac agents in the Cloud.
In this case, I'm choosing the Windows one.
You can also take an agent that
we have and install it on Linux,
install it on Mac, install on Windows,
in your Cloud, in Azure,
in [inaudible] on the machine under your desk as
long as this service can over the internet hit it,
we'll be able to trigger Builds on it.
We have teams at Microsoft that
have certain equipment that they purchased.
So, they use it for their Builds
and they trigger it from the Cloud.
And then on top of that,
they usually use some of our Cloud hosted agents as well.
This gives you
really rich information on what's happening.
And this Build takes a bit to finish.
So, I'm not going to wait for it to complete but what
I do want to show is a completed build.
So, I'm going to go back to Builds,
and I'm going to go back through the history.
So, I'm going to use this theory here to click
on the previous one that was completed for it.
And I'm going to find "artifacts" button.
Bare with me one second here.
So, I was playing with these builds earlier
and there's a good chance I broke something.
Yeah, this build, does not create artifacts.
Let me find one that did.
It wouldn't be a real demo if
I didn't have some kind of issue. That's fine.
The best time I ever had was at one conference
when the engine failed to my Internet demo,
that was really the best.
After that, nothing really scares you anymore.
Geez. I wonder why it's not here. All right.
Well, I was showing this to myself earlier but,
of course, when I want to show it
to people, it's not working.
So, basically, there's an artifact button that appears.
I must have broken the build
somehow because I was messing with it,
but the artifact folders will let you download
everything that we've built up in the
cloud as a zip file.
Or, again, as part of those built tasks,
you can configure it to upload it somewhere.
Put it in a [inaudible] share .
You can send it up to Google Play Store.
You can actually submit
the build if that's what you want to do.
Of course, some of those things aren't
necessarily recommended best practices but
this is a very very flexible build engine
that lets you do whatever you need to do.
Sorry, I failed you in the last demo there but trust me,
it does work and I'm
sure am going to kick myself when I figure
out what happened to that. All right.
So, for the next demo,
our third and last demo that we're going to show today.
So, this demo is going to be all about the backend.
So, let me switch gears a little bit
and go into the VSCode.
This is a sample node app
that I've basically decided to demonstrate and,
you know, you don't build node but you
can run a bunch of stuff against node
to make sure that you know package is ready to
be deployed somewhere and you can package it up.
So to that end, let me me show you how that's
configured inside of the Cloud.
I'm going to go back here to my
"Builds" and I am click on the "Game service" one.
So, I can click right
here in the dots and I can say "Edit".
And now let me show you all the steps
that I have implemented inside of there.
So, what this does is it does the unit install but then
it runs the unit test that
the sample already has built into it.
Then it installs the Azure functions pack.
I didn't build the sample so I'm not sure why
you did that but it's probably a really good reason.
Then it runs a security check.
By running the Run Security Check Command, again,
these are all the various extensions
against the person added on top of the baseline.
Node package, I'm not a node developer but I
can show you that you can really
customize this to be what you need to be.
And, at the end of it, it creates
an artifact that's ready to go.
You can configure it with
our Release Monogement System as well
that will push it into the Cloud of your choice.
Again, you can push Azure,
you can push to AWS,
you can push it an FTP server,
whatever you would like to do and it all just works.
Maybe I can actually show what I wanted to show
earlier through here so I'm
going to, why not just give it
a shot because I'm just
feeling silly that that didn't work earlier.
Click on one of these builds that completed.
Yes, there it is. So that's what I was missing earlier.
I'm going to zoom in a little bit just to show you.
When a build is successful and
when you're not mean, you don't break your build.
You get an "Artifacts" button here and
this "Artifacts" button, if I click on it,
lets you download or
explore so I'm going to hit "Explore" and
show you that it created
a zip file just like we intended.
I've downloaded the zip file. I've looked at it before.
It takes a minute or two so it's pretty
big because of all the little packages and such but
really this thing does work
and it gives you great traceability
that the beautiful thing about the fact that
this product is a sweet of ours,
is you can use it however you want.
You can choose just to use Built
let's say or Source Control,
but if you use the agile planning
and you plan your work against the code you commit,
then you take the committed code and do the build.
You can see all the way through
and you have full traceability.
You can click on a "Work Item" and
see the builds that had
triggered the commits were associated,
makes tracking work on
a team of any size just really much, much easier.
That's how we actually work.
Microsoft uses this to build Windows.
Microsoft uses to build
all the games that we've built out of our studios.
We've built XBOX with this.
We've build our hardware with it. It's a planning tool.
It's a storage tools, builds,
releases as Wikis, and has tests, lots of capabilities.
I want to show you one particular thing
as kind of the last big demo,
which is pull request experience that we have inside.
I'm going to go and make a change inside of this VSCode.
Again, there's the changes I'm making are silly.
As you can see, I changed
this line like 10 times getting ready.
So, really fixed comment.
There you go. I've done that.
And the VSCode does what the VSCode can do.
It the text detects the change.
I'm going to go ahead and
commit "Another change (sorry)."
I shouldn't be committing every five minutes here.
So, then I'm going to go ahead and
say that I would like to sync
this up but this thing
won't let me sync to master
so let's go to a command line.
All right. What I did here,
I'm going to zoom in to show you is that I've
created a local branch.
So, when I did a commit instead of the VSCode.
That is great user of
the VSCode so it was probably my fault.
It didn't realize that I wanted to commit
here and I have a policy against Master.
I don't allow commits to Master.
So this is how Microsoft actually builds our software.
I'm going to demonstrate that flow.
I have a new branch, in this case,
over command line I was able to
commit code to that new branch.
So I'm going to go into the VSTS and
show you what that looks like now inside.
I'm going to click on "Code".
I'm going to select the correct repository.
Again, you have unlimited repos you
can create in here so I'm going to
select this repo and I'm going to go to my commits.
Sorry. My pushes, branches. There you go.
So, under my "Branches",
I have this branch and
it shows that there was a commit to it
and it shows that there's
a new pull request available for this commit.
Now, the reason why I have it set up this
way is to protect my master branch.
I want people to review the code that's coming in.
I'm going to show you how I prevented
my code from going to master.
I messed up the first part there.
I'm going to go to "Branch Policies".
Branch policies is created out of necessity.
We've had to create a bunch of stuff
inside of the VSTS to scale to the windows team, really.
They're the ones that drove a lot of
these capabilities and we've
put this into a real product
because again, we build on the real product.
We don't have a build system behind the scenes,
as one system and then you guys get
some other product from us. This is the real thing.
They have all sorts of really challenging situations
because of the 4,000 developers they
have working on the same source code,
but we don't have as many challenges
so I've just made one reviewer.
And I've even cheated, I have allowed
myself to be the reviewer
so I required one reviewer to
approve it before it goes to master.
I'm going to go ahead and actually go for
that flow and show your pull request experience.
I'm going to create a "New Pull Request".
In the real world this will be going to some other people
but in my situation its just going to me.
Right away its using whatever I committed
to get as my comments as the thing.
If I wanted to associate it
right now with one of the work items they have,
like let's say this was the one.
It's not the one but let's say it was,
this is where the trackability starts to come in.
I can do that here and make sure that
there's a track back to the work that was assigned to me.
So, I'm going to go ahead and create the pull request.
Not that the pull request been created.
I can, unfortunately from
my company here at my fake company,
I can start review it which is yes, I can do that.
I can go in and they can take
a look at what the changes were.
I can actually go back and click here
and see what the work item was.
So, there's a lot of linking back and forth.
If this was the real work item,
I would be able to go back in and make
sure that I understand what was the work that was
expected before I did the pull request verification.
Again, here, I can see
the files that were changed so I can say, "Okay.
That looks good to me." I can
come in here and actually add a comment.
I can do things
like reference work items inside the comments.
Let's say I looked in here and
something wasn't right and I'm like, "You're forgetting.
There was another task assigned.
You didn't complete it. You should have
committed as part of the set."
So, I could have done that here or I could do at
other people and basically
get an email to be fired off to them and say,
"Hey, I don't think this looks right.
Could you double check the code?
Does that look right to you?" So that's very powerful.
I can just add my comments
into this and it's all saved so,
like a year from now you can come
back and see why this pull request was
approved and let's a security bug in production.
Not that that ever happens but at least you'll be
able to see what happened historically.
I'm going to say that I not only feel great about this,
I actually went to auto complete the approval process.
I want the changes to be committed up to master.
So, I'm going to hit "Set Auto Complete".
I'm going to say,
"Delete the README fix branch inside of the VSTS."
It's still available on my machine, right?
But, in the VSTS, because we're merging from there.
If the merger succeeds,
it's going to kill it, clean it up.
And I'm going to say, "All right so I feel great.
Auto Complete has been configured
and I'm going to approve it myself,
which is again something you shouldn't be doing.
But once I approve it myself,
there you go. The changes have been committed.
So, if we go back to builds,
we will now have a build running for
the service and it's running
only because we went through that process.
As part of this demo, I've shown you a lot of stuff but
one thing I promised to show you at the end was this.
There you go.
I sat there with a stopwatch
so anywhere between 8-12 minutes.
If you get really lucky it's like immediate because
you're somewhere in that window of them waiting to check.
Basically, this is where
the Unity Cloud Build picked up the changes that
I made in the VSTS to make it
repo and it's now building inside of it.
So, between the Unity Cloud and our Cloud,
you can build Mono, you can build Unity.
In our Cloud, you can build C++,
you can build Android applications.
Again, we have Mac Linux and
Windows-hosted agents. You can have your own agents.
You can configure it against other
people's agents like I did here.
You really can do CI against your source code.
Any problem you have
can be solved pretty much with this product,
to this refill and if we're missing something,
we're here to make it better so do let us know.
Trust me, the Minecraft Team
is one team that I'm talking to actively because they
have some suggestions and we need
to help them out there so we will make
this product better even for our game studios
being part of this product and making a solution.
Thank you very much. If anybody has any questions,
I'm available. Thank you.
For more infomation >> Good Friday Services, Passover Celebrations Begin Friday - Duration: 0:33. 
For more infomation >> Savitarnos portalas „Card E services" - Duration: 1:20. 
Không có nhận xét nào:
Đăng nhận xét