Advanced Binary Management for C/C++ with JFrog Artifactory

hi
good morning everyone uh so i’m jonathan
roccolo
and i will be uh your speaker your
presenter for today with you know
so uh quickly uh the agenda for today
uh i would like to present you so i will
start with a quick introduction
about uh j frog uh to just
for the people who don’t know us uh for
now
i’m sure you know us but just in case
uh i will take a few minutes also to
give you a quick overview of the jfr
platform
uh what it means what are the different
services and components
and what we want to uh
where we want to help you and how we
want to
to to help you in your journey
and after this uh let’s say i live i uh
i live a overview i would like to go
back to the basics and talk a bit more
about
uh development lifecycle with a quick
focus
regarding uh c plus plus development
lifecycle
challenges and then we’ll talk about
binary repository what is it exactly
why do we need it and what is j for the
artifactory
in this area how it can be used
for cc plus plus but other
challenges other package types within
your company within your organization
and after explaining some concepts i
will
take some minutes to show you a quick
demo
of all the things i will explain and we
should have some
additional minutes to address some
questions
if i don’t have time to answer all the
questions or
if i’m not sure to to for being able to
provide you a clear answer
no worries we’ll address those questions
offline
uh with follow-up email so feel free as
i say to ask any question in the
question box
so let’s start with a quick introduction
about jfrog so jfrog as you may know is
a
an israeli company founded in 2008
now we have offices all over the world
in the us in india in china in japan
in europe and israel of course we are
more than 500 employees in all those
offices and
we have more than 5 600 paying customers
for now
paying customers because we have also
community
and open source edition of our products
so but we know we have this base of
paying customers
what is interesting is that uh part of
those customers
we have almost any kind of companies and
we are proud to
to have 70 percent of the 1400
companies as part of our customer
we have an interesting growth
with almost 150 new enterprise customers
monthly coming to use our products
and uh we are also interesting
statistics so
growth in terms of
ar but also in terms of usage of our
products we know for example that uh
today we have
two billion uh dependencies downloaded
permits
from our bintray distribution platform
and around three million
enterprise developers are using on a
daily basis
our products we are also
community champions and we are
involved a lot with different community
so uh if you’re here i guess you’re
familiar with conan
and you know that conan is part of jfrog
you might know so that we are
hosting and managing conan center at
jfrog
so for the cc blue space community and
conan community
but we are also involved with go
community for example we are managing
and hosting
go center which is uh a center for
go modules uh we released recently uh
last month’s i think chart center which
is the first
uh central central repository for helm
charts
with uh security analysis and
we are formed for a long time
also involved with community for java
and other package type
with bin tray last but not least we are
we are considered as devops unicorn
because devops is really the area where
we are involved these slides uh
show you uh a short list of our
customers
uh what is interesting here is not so
much the name even if it’s interesting
to see
uh famous names like google or
oracle nasa and so on
but what interests me is that
we have customers in almost any industry
area and this is a thing that
is very interesting for me is to see how
the develops and this
software development revolution or
yeah evolution is embracing
all the industry area it’s so you have
the
let’s say the cool kids that are of
course
in this area like google amazon
and that are shown here in the devops
world
but it’s interesting to see that even
uh companies that are pure retail
company like
walgreens targets are also
even involved in this devops
transformation
and trying to modernize their
software delivery lifecycle to change
at jfrogand why we have
we are so successful i believe is
because of
our uh approach which is from the
beginning
uh unified and universal approach first
of all
all our products are
built in a universal
with a goal to provide universal support
which means that we started with art
factory as a universal binary manager
which means that it supports many
package types not only java or docker
but we are more than we are supporting
more than 25
package tags for today but we are also
universal in this
way you can integrate artifactory
with the ecosystem we have
integration with more than 50 technology
partners
you can integrate our products with most
of the tools you already have in your
tool chain
such as ci servers code analysis tools
and anything you can find
in this kind of tool chain we provide
hybrids and
multi-cloud support also which means
that all our product can be installed
on premise on the cloud any kind of
cloud
but you can also go with a sas offer
provided by jfrog
running your j4 platform on our sas
or you can also go with hybrid solution
with a combination of your own private
cloud on-premise
and sas offers we provide
a continuous security along the tool
chain
we have a dedicated tool for that called
j for x-ray
that allows you to scan and give
analysis and reports
from the beginning of your tool chain
when you start to consume
external packages to the end of the tool
chain when you
distribute to the runtime
your releases and
all the products uh we built are
building a
fashion that can be uh highly available
allow you allowing you to have horizons
tall or vertical scaling
uh to scale uh whatever
the needs you have regarding your
business
so what we have in
the default platform today i guess some
of you
are familiar with the first product art
factory
that we can see on the left of this
diagram
art factory is the flagship our flagship
products are jfrog
this is the one we built and we built
the companion
and all the products are using art
factory uh
for uh access authentication and
uh other uh integration this is really
the base
of the jfoc platform so
art factory is our universal package
manager
and the idea with it is to be able to
manage your artefacts
artifact you consume from
subparty repositories artifact your
produce
and to track them with all their
metadata so
this is really where you start to manage
binaries and not
only code the second product
uh we have in the platform is called
jeffrey xray
it’s a security and license analysis
tool
the idea with x-ray is to be able to
scan any binary stall in art factory
and to give you a result regarding
first of all it’s recursive analysis
showing you all embedded binaries within
your own continents
but also to give you reports and
analysis
regarding known cvs and license
information
x-ray allows you also to automate
things policies you want to apply
when you detect something wrong like a
new cv
or license that you don’t want to have a
new product
on the right side of triforce x3 you can
see distribution j4 distribution
this is a service we released
two years ago now and
distribution the main idea here is to be
able to
ship in a secure atomic and
imitable way your releases
to production time to production sites
what i mean by production site is
to ship your binaries your releases
as close as possible to the final
consumer
to what we call the edges and
for that we also release the
jfrog edge nodes uh components
which are kind of very light artifactory
for read-only to provision
edges edges that can be
kubernetes cluster if you are managing
your own runtime
but it can be also your uh
final consumers like your your own
customers
for delivery purpose or it can be
your data center
any places where you want to consume
final releases and you want to make sure
those releases
this set of packages are shipped
together
in an atomic and immutable way
at the bottom of the diagram you can see
default pipelines
this is a last kid from jeffree
it came from the acquisition of shipable
and it’s a declarative cicd tool
that covers and allows you to automate
the entire stool chain from
code repository to the runtime
it integrates obviously with all default
tools
so you have integration with all the
default products
but also with most of
uh devops tools in general so you can
integrate j4 pipelines with
your existing ci servers such as jenkins
or with your jira with a kubernetes
cluster
or any kind of tool you already have in
your organization
last but not least on the top of my
diagram you can see
mission control and insights mission
control
is a central dashboard to
control and monitor all the default
tools
along your tool chain insights
that is part of mission control is in
charge of
gathering metrics and
give you tendencies across the different
tools in your tool chain so
the main idea with it is to enable
what we call data drive and devops and
to get
feedback flow from the tool chain
as you can see with this um this
platform
and this is the main goal we have at
jfrog
we are we want to cover the entire
space or gap that is between
the code repository let’s say your git
and the runtime and with this set of
tools
we are covering the build the testing
release and deployment phase
but we are not managing the runtime yet
or
code repository
so uh let’s go back uh a minute to
something more
let’s say basic or day-to-day work
let’s talk a bit about development
lifecycle
and what it means
the main purpose when you are doing
developments
and when you are building software is uh
to release this software at some time
and to
run it in some runtime with
uh the evolution of
software management during the past
decades
let’s say with uh the
agility then the develops and all these
nice practices we built
we are we all agree that we need
iterative
and uh continuous uh
improvements in our processes this is
why
this kind of diagram is uh
quite common and the idea is always the
same when you
are building a tool chain you start by
coding
coding in your own language you build
your code to generate some artifact
binaries
that will be tested released distributed
to the edge
deployed to a runtime environment and
based on monitoring on metrics
you will learn get some knowledge and
you will code again and make your
software better this is the main idea
if you look in a in the timeline
of this iterative process it’s
always the same you start by
some source code so in fact
you start by source code and consuming
dependencies
because source code relies on
what you are using as dependencies there
are only few projects today that starts
fully from scratch so the first thing
the developer
does uh in a company one is
his writing software is to write its own
code to choose dependencies
you want to use and then at the build
time
it will generate some artifacts and
will deploy them somewhere this is uh
basically
what a developer is focusing on
and it’s pretty simple it’s pretty
straightforward
a few weeks ago we
gave our first conan training
for c c plus plus people who want to use
conan it was called conan days and there
was
a full days of training it happened
remotely
but i think it was really interesting i
guess some of you were part
of those training days if you were not
part of it
the good news is that we will have
another training day other training
classes that will happen in the future
we will
send you some information uh in the
follow up email i guess
if you are interested but in a nutshell
what we did during this um this training
day
is first of all to show that
in uh ccp c and c
c plus plus world development lifecycle
is not
so trivial and so easy
this is the kind of diagram we add at
the end of the training
for managing the full project and i will
try
to give a quick summary of what we did
during this training but
[Music]
i really encourage you to have a look
for the next conan days
and to see and go to the hands-on
and to build this training step by step
during the training we we built a very
simple application
with a graph of dependency that you can
see on the left
of the diagram so there were some
libraries a b c d
and two different applications with
different component graph
for each application and
the use k was the following we had a
developer
working on a particular library
the library b on this graph
and working on a new feature within a
feature branch
we show how you can automate
the the tool chain
on a commit on its feature branch how to
test it
and then after merging the pull request
how conan were used to
first of all get this component graph
and know that this change on the library
b
will need to rebuild a set of libraries
in my case library d and the application
one the product uh package
and based on this component graph i will
be able to
first run in parallel below that we
were able to run in parallel and how we
were able also to
after creating the
products package to store it
uh in a repository manager but moreover
to generate
the log file for this particular package
for this particular build
this slot file used
to then guarantee immutability
of this particular build i will show you
um
this log file during the demo just for
people who missed it
but the main idea here is that in
during the training we stored this
particular file in a command metadata
repository
and this file gives you the exact
component graph
that were used at the build time
of a particular common package
last but not least during the training
what we did
is to use the
product package to
and the log file to install this
application deploy it
and generate then a debian package
that we stored in artifactory
and this is more or less where
i will start my demo later on
so during this training we used
a bit artifactory in the background we
explained a bit about it
but we focused mainly
on canon itself and cc plus plus
but in terms of
binary managements if
you are talking if you are speaking
about conan you have to understand that
conan is relying on a
package type conan is a package type and
at some point you need
to store those packages and
what can you do to store those packages
to share it within your organization
you can use a shared file space
so an ftp basically this is what people
used to do
in the past not with canon but with
tools like maven for example where you
can rely on a pure layout
and it can work to some extent
but uh when you start to have a specific
protocol
such as with canal or with other
technology like
docker or nugets and you start to have
this protocol an api how you will handle
it
this is the first thing so how you will
expose
api and uh
and all the logic needed to
fetch the right dependencies and so on
another alternative and i’m sure
many people here did it in the past or
still doing it
i did it in the past is to use your vcs
your git repo your svn or whatever to
store
your binaries the result of your build
the thing is first of all vcs are not
built for that
vcs are called code
source code management so it’s for
code it’s not for binaries and why it’s
first of all because the main idea with
the vcs is to be able to give
text to merge them to compare
a different version of a file which is
not doable
at binary level there are other reason
why you don’t want to do that for
indexation
issues uh but the main thing is that the
vcs is not
built to do that also if you look at the
underlying mechanism in a vcs
like git
the the versioning is not built
to store binaries it’s stored by
contents
not by name and
[Music]
the idea with binaries is different
from code in code you want to check the
diff
you want to be able to go back in time
while in binary you want to be able to
track to version and to keep
immutability
of your binaries so
uh the conclusion is uh quite obvious
but
this is why we built binary management
tools and
today it’s maybe obvious to say that
but believe me 10 years ago it was not
so
what can you do to store binaries is to
use a binary management tool
and if you look at binary management
tool
there are plenty of solutions on the
market
but if you look at what you want
first of all you want some functionality
so if you work with canon for example
you want to have
a binary manager that will work with
conan that’s
pretty obvious you want
security you want to be able to control
who
can access to what binary
what package within your binary manager
binary management tool but you want
also to be able to track who accessed
uh who produced which binary who
downloaded which binary
and so on and
moreover you want to have availability
at the time you start to build
automation and tool chain
using a binary repository manager this
binary repository manages that to be
the back end of your tool chain which
means that
it’s also a point of failure for your
tool chain
and if your delivery process your
engineers are
relying on your tool chain losing this
binary manager
or having done time on it means that you
will have downtime on your entire tool
chain and your degree process
which is not suitable for your business
so in terms of functionality
uh if i want if i look
at a more enterprise grade level
i want to be able to have control on my
storage
i want to be able to scale in time
because
i know that i’m producing binaries
every day and so this storage will
increase
every day i want to have performance and
not to be impacted because my storage is
growing
i don’t want to have an impact on my
performance
i want to be able to address different
technologies
because even if i’m a cc space engineer
working with canon and because i went to
the conan days i know that
i’ll need at least some generic
repositories
but if i want to address also the
delivery parts
i might need some debian repositories or
rpm repositories or docker repositories
something from another flavor that is
more suitable for
deployment and runtime i want to be able
to manage version and updates
to have easy maintenance and
administration
in terms of security i want to be able
to authenticate and give authorization
to my people
to keep integrity and traceability of
my artifacts basically who’s doing what
and making sure that crucial information
are kept forever or at least for the
time i need them
and as i said i want availability and
performance
i want to be able to have my local tool
chain
with no downtime but i want also to have
a distributed team working with good
performance
so what about when i have engineers
spread it
all across the globe for my organization
how can i make sure they will have
all the same performance and same
availability and sla i want to have
h a and dr i don’t want to lose data i
want to have node on time once again
and caching this is for the performance
and one uh of
the solution you can find and uh i truly
advise you
to have a look to it this is the main
purpose for today uh it’s jfrog art
factory
and white geforce factory is a good fit
for all of those challenges
it’s first of all because jfrog factory
provides an advanced storage
solution first of all
in j4g art factory you can really choose
which
storage provider you want to use you can
use a local file system
or an nfs you can store your binaries
as blob in a database you can use object
storage
on amazon azure or gcp
or even any implementation of s3
protocol
for on-premise on-premise
object storage you can change different
providers you can use local caching when
you have a low performance
storage system
you can use sharding implement residency
across different charts across different
data centers
and it’s really
flexible and advanced in term
of what you can do in terms of storage
both in performance stability and
reliability
arts factory itself is as i said a
universal binary repository manager
which means that you can store all kinds
of artifacts and resolve all kind of
dependencies from there
you can use it as a proxy or remote
repository
and it integrates with
all native package manager
we have also integration with most ci
servers
that exist like jenkins bamboo bitbucket
azure devops platform and of course our
rgf pipelines
and the main idea as i said is that
using artifactory
as your binary manager with its
metadata system you can really
use it as a backend for your tool chain
and consider it as a single source of
truth for
your binaries
very quickly i said it you can store
more than 25 packages
in that factory and also generic
packages
so in fact any kind of binaries
even mp4 pictures documentation
current packages of course and so on
so in that factory as i said you can
store any kind of binaries
but more importance with
all those binaries is also to store
all the metadata build results the
concept
the context of your build what happened
when it happened
did i checked and tested this library
so this is where you can start to really
use artifactory
to both store your binaries but also
track the lifecycle of those binaries
along your tool chain
[Music]
i said it’s integrated with most
binaries and
let’s have a quick very quick look to
artifactory main components
so i will go pretty fast on this one
just keep in mind artifactory is
uh available through http https
there are three ways to communicate with
that factory
through the ui through webdav there are
still
some companies using it or rest api
keep in mind that even when you go
through the ui
behind the scene that factory is using
rest api to communicate with its
backend what does it mean means that you
can do
everything in our factory through the
rest api
and we know by statistic that more than
90 percent of the use of that factor is
done through rest api
then in a factory you’ll find a caching
layer for performances and
the core concepts which is a virtual
file system
of art factory virtual file system
because
it’s uh divided in two parts the
binary store i mentioned before this is
where you specify if you want to use
object straight sharding
the local file system or whatever and
the second part
is the database database that will
contain
all metadata and here will take just
one minute to give a bit more
information about artifactory and how
art factory stores
artifacts when you deploy a file in that
factory
art factory calculates its checksum
and will store it in your file store so
in your s3 bucket or your local file
system
based only checksum so here i deployed
the file with the checksum that starts
with
two efc blah blah blah and
so this file will be stored in a folder
starting with 2e
under the name equal to its sha 1
and this is the actual binary
on my file system in the database
i have a table called nodes that
contain references to all occurrences of
this file are in my art factory
so here i have a record that says that
my file
with the checksum to efc
and so on is stored in the repository
libs with local under this pass and it’s
a jar file
what does it mean means that if i have
the same file
with the same checksum even with a
different name stored
in a different repository or different
paths
under the same repository i won’t have a
duplicate data a duplicate binary on my
file system
which means optimization of the file
system
uh so this is one of the the first
advantage of
this checksum based storage is the
duplication of size
for content packages those are
small but when you start to play with
promotion and having them in several
places
it can be interesting when we start to
talk about docker images or
yeah images are a good example it starts
to be even more interesting in terms of
storage optimization one
very interesting thing also is that copy
and move operation
are very cheap on that factory because
when you copy a file from one repo
to another one at the end it’s just a
new record
inserted in the database
deletion also are just a database
operation
and then there is a garbage collection
in our factory that will delete
and reference file from the file system
but
the delete operation that you are doing
as a user
is something very fast that is just on
the database level
and also with checksum based storage
we do not need any luck
at file level which means uploads
download
operation are very fast and all
replication i will explain a bit what
our replication
are checksum based so we avoid to send
files
that already exist on the network
and this provides better performance for
the file system
because of the non-looking uh stability
in
term of for the searches and
performances because
all searches are database searches not
by stem searches
okay uh so as i said in the database you
have
all the metadata all the information
stored
about your art effect so it can be built
information it’s
calculated metadata from the package
revision number version number and so on
but
also custom metadata properties
everything you want to add to your
binaries
by default factories using the daddy
derby database
uh just keep in mind this is uh only for
small medium installation
when you go at company level you should
consider using
another database and we support any
relational database such as postgres
mysql and so on
as i said uh art factory supports rest
api for
everything we have also a cli tool
that will be shown during the demo very
quickly
keep in mind the cli is just a wrapper
for the rest api
optimized wrapper which means that you
can do
parallel requests multithreading and
you have some logic implementing the cli
but at the end the cli is just
using rest api
we have plugins for ci we have uh
also the capacity to add user plugins
within art factory
to implement your own logic your own
features if you you want to implement
some
workflow and processes within art
factory
and and metadata are very important you
will see
why in the demo last but not least
some points when you should think about
enterprise grade repository
as i said artifactory is built to be
universal and agnostic
for deployments which means that you can
deploy it
on kubernetes we have official m chart
for that you can deploy it on vm on
windows on unix
on your mac you can install it with brew
with debian packages rpm packages
we support multi-cloud multi-us
it’s really the goal is to be universal
and agnostic
we have hybrid model we support
replication and multi-site topology this
is
when you start to have people in
different
location as i said before and to give
them
same experience same performances and
all our products support hca deployment
which are pure active active deployments
which means that
all nodes within a cluster within an
architecture cluster
can uh self download upload requests
in the same way and distribution
is last point as i say to the to the
edge
this is uh i forgot i added this point
because
it will be released very soon uh we
announced it uh
few weeks ago during our uh
user conference but something very
exciting for
people with massive deployments we are
releasing a peer-to-peer
download capacity on that factory to
also
increase performances when you have
massive edges
or endpoints to to upgrade
in parallel
okay and i think i
spoke a lot about uh
the slides and now it’s time to show you
uh a quick demo to
to go further after the conan days as i
say
so i’m gonna share my screen
first of all
okay so application and i’m going to
start with a terminal
so you might be able to see my screen i
hope it’s
big enough and i will start from
almost where we stopped during the conan
days training
so for the people who were there
what we did after building uh
the application is to use aql
aql means art factory qre language
and the cli to
find the right command package
to ship um as part of our release
so here i have a five spec it’s a json
file
that can be consumed by the jfox cli
and this size spec is simply using a
nut factory qa language statements to
find
all items from a particular repository
connect metadata
and the files i want to find are lock
file
so canon lock files produced by
a particular build so a build with this
name and this number and with a property
profile
equal to release gcc6 so
running these commands allows me to find
the right five spec and this is what
we did during the training we use the
jfox cli
as it to download the fast pace
and here after that what we did
is simply to run a canon install command
to install the application we tested it
and then
we have generated a debian package
called uh app debian if i remember
we deployed it in at factory we tested
it
and what we did was a promotion
of these artifacts to a qualified
repository so now at this stage what we
have in art factory
is a debian package deployed that
contains
our application and
we have also the a particular object for
this debian package
a bill information object so a set of
metadata
that reference the debian package has a
generated artifact
and the canon log file as a dependency
of the build and why i’m talking about
that because
for today i will show you how to
navigate
to navigate in the other way around
so first of all i will go to another
folder on my machine here and i will
show you
another 5 spec
which is a bit different from the
previous one
the previous one we were starting from
the canon log 5 looking so we knew that
we had a can unlock file produced by a
particular project with a particular
number
now i want to do the other way around i
know that
i have somewhere uh build debian
app with a particular number and
i know that this build is using a
particular dependency
a particular content package and i want
to find it sorry a particular
a particular conan log file and i want
to find
it to be able to retrieve my command
package
and test it so here i have this
file spec which is using again actual
and you can see it’s a bit different
because
with aql which is a very powerful tool
you can navigate in all
properties and entities stored in that
factory and here
i’m saying i want to find also in conan
metadata
a log file but i want
a log file that is
a dependency of a module
that is part of a build named debian app
with the number one what it means
here i’m not looking for the bill that
generated this
file but for the build or for the
dependency that is included in this
build i know my build and i want to find
the dependency
and as before what i can do is
first to use a cli to run a search
command
and with no surprise here i can find my
log file so here it started in my
factory
i can see this is the one i’m consistent
with the previous example i can see that
this
command lock file has been generated by
the build
product master with build number seven
if you remember this is
what i was looking for on the
log file itself so i’m consistent and so
now
what i can do is to download it
run the command install command and try
it
so so here with the cli rt download
using the js the file spec
i got the file and now i will run
a current install command
you can see 12 and now
i will just give a try to the
application to see
if it works and it works so
it was just to show you how you can
navigate through the metadata and the
importance of metadata
i will just stop sharing this and
i will share again my screen but now i
will go in
my artifactory
okay
let’s go to art factory here it is
and we i’m going to start with
the artifactories that were used
uh for the entire lab
so here is that art factory i’m on
what we call the package viewer i can
see my
debian application the different command
packages
uh sent to my art factory
and uh so here if i go in my builds
i can see the build dividend app with
build number one
this is what i uh
i was working on with my xql and my face
pack
so what i did with my aql was to find
regarding this build name
with this build number i wanted to find
the module that contained a dependency
and i wanted to find this dependency
so here is a log file i
was looking for with my spec and this is
what i downloaded
so here you can find the dependency id
so the lock file that i will use as a
dependency
to generate my debian package okay
you can see that this debian package and
this was parts
of the conan days training
so this dividend packet has been
promoted in a debian uat
local repository and
so i can navigate to it here in my
debian repository see the debian
information
here i have the build part where i can
see
who has produced this
debian package and i can navigate back
to uh the build itself
and then go to the log file that is the
dependency
and here i can see it and see also that
it has been used only by this build so
this is what i wanted to show you in the
command line
with pure rest api i was able to
navigate
back and forth to dependencies generated
packages and so on
and i have this traceability and thanks
to the lock fire i have also this
immutability of my command build
now i mentioned a bit about advanced
repository features and what we didn’t
show you
during conan days was some interesting
things regarding
uh the repository here if
i look at repository structure in my art
factory
so i can find the different local
repositories i used
for my lab so here i have the app
debian uat local where is my promoted
debian package
i have the conan used by my developers
as a canon local where is my thermal
product package the current metadata for
my log files and so on
what is interesting also is that you can
see here
in the last column of
this view there is a repetition column
and if i have a look let’s say to the
current metadata
repository in the replication tab i can
see that
this repository is configured to
replicate all its binaries every day
at 1 pm to
2 different targets in fact two
different
canon metadata local repositories but
located in two different
artifactories and what is in
any delete change of metadata
deploy write operation done on this
repository my current metadata
repository
will trigger the replication and this
replication this thing
will be done on the two different
targets what does it mean
means that if i go now on one
of those targets let’s say this one
which is a different artifactory
and okay
i didn’t login okay if i log in
okay so here i’m connected to an art
factory that is
uh running in sunnyvale and you can see
on my map so this is a map provided by j
for control
jeffrey mission control i’m connected
from sunnyvale here i have the other
artifactory where i replicated my
packages in europe
in saint petersburg but what is
interesting here is that if i look at
the package view
here i will find sorry
i will find different packages because
this is used by different
teams but if i filter on canon
here i will find all the conan packages
produced from the other data center
pushed in this artifactory
and sync to my u.s sites
what does it mean means that if an
engineer
in the u.s site now run the same
sql statement the same five spec and the
same can uninstall command
as i run on my own data center
he will get the same result he would get
the same
current package he can consume the same
debian package because it’s also
replicated
so here if i have a look to the debian
package no
okay it’s not indexed but here i can see
that i have the same build
i have the same build information the
same metadata
and uh yeah and i have my uh my debian
package also
deployed on my art factory so what it
means
if i go back to my map
i have some developers working on the
feature branch
in toulouse this is where i live after
pushing to their git repositories this
has generated the
product package command package after
merging the change
and based on art factory replication
because i’m using it all the metadata
all the binaries are synced to
the distant sites which means that now
now
developers local developers on each site
can consume
their package from their local instance
their local
canon repository and this can be applied
to
the debian packages docker images helm
charts
and so on
okay so
i will stop sharing from now
and go back to the slides
okay
so um what’s next
uh first of all uh i i
really encourage you to uh have a look
to the next conan day
edition and to the training uh it was
pretty hard to show you all the things
uh i wanted in a single hour
so really have a look to it
then you can go on our website uh to
ask for a trial we have also a not
factory community edition if you want to
start only with conan
but if you want to start with more
packages
and advanced features you can have a
look to the trial for 30 days it’s free
go to our documentation page we have a
j4 academy with a lot of
video content and training materials
and stay tuned we have other webinars
coming
white papers and so on