M183: Start making a software product from configuring its build pipeline - YouTube

Channel: Yegor Bugayenko / 袝谐芯褉 袘褍谐邪械薪泻芯

[0]
hey
[1]
i'm working with a number of software
[2]
teams uh which develop software and they
[5]
have quite professional programmers
[6]
there and architects over and over again
[9]
we are having the same discussion with
[10]
them and i supervise them so i do not
[13]
participate in the development of the
[15]
code there but i look at what's going on
[17]
there and i
[18]
more or less control uh the things that
[20]
are happening there and um what i see is
[23]
happening there is that they they
[25]
develop the code they write the code
[27]
they they get the product more or less
[29]
ready they
[30]
they make the functionality but
[32]
they do not
[34]
configure continuous integration they
[36]
don't configure release pipeline they
[38]
don't
[39]
automate unit tests they don't use
[42]
static analyzers they don't do anything
[44]
which is which is in my opinion uh par
[47]
is part of the build pipeline the
[49]
important parts of the build pipeline
[51]
they just have the source code they use
[53]
uh ide where they develop that they run
[55]
unit tests when they have them inside
[57]
the ide but they don't package it all
[60]
together and when i tell them that this
[63]
is important
[64]
the same answer comes back to me over
[66]
and over again they say it's not
[68]
important we're going to do it later
[70]
because what's important now is to make
[71]
the functionality it's important to make
[73]
the features to make sure the software
[75]
works when we get the product when the
[77]
product is stable then we will spend
[80]
some time and
[81]
do these things we'll automate
[83]
everything and we package and deliver
[85]
and everything and everything will be
[86]
ready and sometimes they even give me
[88]
the metaphor like this they say uh we're
[91]
building a house so it's too early to
[93]
paint the walls the walls we put the
[95]
foundation there we are we're making the
[98]
concrete structure of the house so and
[100]
you're telling us to
[102]
to put the picture on the wall it's too
[104]
early for that and i disagree with that
[106]
as you can probably imagine so i believe
[108]
that this is a
[110]
strong and bad misconception of what is
[114]
the foundation of the house and what is
[116]
painting the walls so i believe that any
[119]
project has to start with the build
[121]
pipeline and configuring build pipeline
[124]
should be the first step in any project
[126]
maybe okay maybe the second step so
[128]
probably the first step should be the
[130]
making the readme file and in the readme
[132]
file you explain what the project is
[133]
about how it's gonna work so you
[135]
basically draw the concept and you show
[137]
it to your friends and then when you
[139]
understand the concept then you start
[141]
with the build pipeline you think about
[142]
where are gonna be unit test placed
[144]
what's gonna be the the package manager
[146]
what's gonna be the build manager how
[148]
we're gonna deliver it to to production
[151]
so you you put it all together and this
[153]
is the foundation
[154]
and then you start building the walls
[156]
and then you paint the walls so the
[157]
functionality and the features
[160]
these things are the decoration of the
[162]
house but the foundation of the house is
[165]
actually the
[166]
the framework i mean what's the right
[168]
name for that a framework or the
[170]
scaffolding for
[172]
uh for your for your product so turning
[174]
it upside down and thinking that build
[176]
pipeline will be delivered later is a
[178]
mistake why
[180]
uh well because it will be very
[182]
difficult to make it right
[184]
when the product is ready
[186]
when you have a lot of source code files
[188]
it will be too late to use static
[190]
analyzer because you have 10 000 lines
[192]
of code and then you start using the
[194]
analyzer the code the style checker and
[197]
you will have i don't know how many a
[198]
thousand complaints which you will have
[200]
no time to fix and there will be no
[202]
pleasure in fixing that as we discussed
[204]
before static analysis and static
[206]
analyzers are the greatest teachers for
[208]
us they tell us how to develop software
[210]
better so if you invite those teachers
[212]
when the project is ready and it's too
[215]
late so they're not going to teach you
[216]
anything the build pipeline
[218]
the the automated build
[221]
making and and the packaging is also a
[224]
great teacher for you it tells you where
[226]
are the mistakes and this stops you at
[227]
the at the right places so it makes your
[230]
development incremental it makes your
[232]
development uh self-validated at
[235]
multiple points on time if you don't
[237]
have that if you only introduce this
[238]
when everything is ready then again you
[240]
lose a great teacher you lose a great
[242]
control instrument which which would
[244]
help you over the entire life cycle of
[247]
your of your development
[249]
if you don't make your unit test
[252]
automated and you use them sporadically
[254]
sometimes when you when you need them in
[255]
the ide you need this test you run it
[258]
you do another test you run another test
[260]
but you never run them together you
[262]
never control the code coverage of your
[265]
of your of your product you never know
[267]
your code pro code coverage so you delay
[269]
that until later then you you lose a lot
[272]
of instruments which you would have
[274]
otherwise if you if you would start with
[276]
a build pipeline i believe this approach
[278]
is quite immature and uh
[281]
i mean the approach when when we think
[282]
that the product comes first the
[284]
functionality comes first and the build
[287]
pipeline the automation comes after that
[290]
that's
[291]
i believe is wrong
[292]
so i hope you don't do that if you do
[294]
then think again when you start a new
[296]
project start with the build pipeline
[298]
everything else goes after that thanks
[300]
for listening stay tuned bye