canonical-ci-engineering team mailing list archive

[Thomi Richards <thomi.richards@xxxxxxxxxxxxx>]

Hi,

On Thu, Apr 2, 2015 at 9:58 AM, Ursula Junque <ursula.junque@xxxxxxxxxxxxx>
wrote:

> I think Celso has a point: we have lots of things in place but very few of
> them seem to be "production ready". We might not be giving proper attention
> to finishing things before starting others, *as a team*. It was even raised
> during the retrospective that if we finished a component and everything
> that entails, adjusted it and then moved to the next, we would end up with
> better results. Not doing this was one of the reasons we had things
> partially completed last sprint, and I believe we still have time to avoid
> the same to happen in this one.
>
>
I remember that discussion point.

I don't think it's realistic to finish one service, then move on to the
next. What does "finished" mean? We're constantly discovering things we
should improve, or should have done differently as we deploy / test / break
our services (not to mention "as we learn more about micro-services"!).
Additionally, these services talk to each other. Sometimes we discover new
requirements for 'component A' only after we've built 'component B' and
'component C'. Sometimes we discover new requirements for the services only
after working on the deployment code... everything is related to everything
else, you can't isolate these components :D

Software is never "done", it is sometimes "done enough to be used".

What I'm aiming for is that when we discover something we should have done
differently ( "Oh shit, we really should be rotating our log files", "or
no, our message retry policy needs to be tweaked", "nuts, the worker names
we're using in our services are not descriptive enough", "crap, we're not
logging certain events which make debugging failures difficult by looking
at logstash"...) we can make those changes quickly (at least some of the
time), rather than thrashing around creating dozens of merge proposals
which is error prone and slows us down.


> I'm not saying this is not an important discussion to have, I'm only
> questioning if this is the most important discussion to have now. If you
> compare it to the other things we still have to do, is this really the most
> urgent problem we have?
>

We have many problems we need to solve. IMO our deployment & runtime
testing is the biggest thing that needs to be solved, but this is a close
second. I have no idea about the CD issues - I mean, I have ideas, but the
intended design for that system is rather opaque to me.


> Is it that certain that we will have problems and that a library *now* is
> a solution to these?
>

Yes. the list above is a _partial_ list of some of the things we've had to
fix in this sprint already. Most of them would have been fixed faster if we
had infrastructure components in a shared library.


> If the answer is yes and we have data to back it up then fine, if not, we
> might have other problems that need addressing first. Again, I'm only
> raising another aspect to consider the priority of this discussion, not
> saying it's not relevant at all.
>

I think we should be able to multi-task here (as a team, I mean, not as
individuals).

Celso cares about the deployment side of things (or at least seems to, I
don't want to put words in his mouth), and has been (and I'm sure will
continue) doing a great job getting our deployment story robust & complete.

I care about the quality of the code and our ability to create new services
quickly, so that's where I'm going to focus.

We'll need to concentrate on both areas before we can finish the sprint, we
may as well take advantage of the parallel nature of the team to get it all
done.

Cheeers :D
-- 
Thomi Richards
thomi.richards@xxxxxxxxxxxxx