canonical-ci-engineering team mailing list archive

[Celso Providelo <celso.providelo@xxxxxxxxxxxxx>]

First, I don't remember seen my name mentioned that many times in a email
thread for ages. I must have done something terrible wrong. Anyway ...

On Wed, Apr 1, 2015 at 9:03 PM, Thomi Richards <thomi.richards@xxxxxxxxxxxxx
> wrote:

> Hi,
>
> I mostly agree with you, so I'm trimming some of your mail to just the
> bits I have comments for:
>
> On Thu, Apr 2, 2015 at 11:54 AM, Ursula Junque <
> ursula.junque@xxxxxxxxxxxxx> wrote:
>>
>>
>>> Software is never "done", it is sometimes "done enough to be used".
>>>
>>
>> I agree :) But for sprint purposes we *have* to have a definition of
>> done, otherwise, for the very same reason, we would never be done with a
>> story. :) For us, there has to be a definition of "enough", and we're not
>> there yet when it comes to defining a good set and sticking to it, we still
>> overlook things. That was the point I was trying to make, and I believe
>> what Celso might be trying to say there (he can correct me if I'm wrong).
>>
>>
> I worry that sometimes we lose sight of the fact that after the sprint is
> completed, this code doesn't go away - we still need to support it. The
> acceptance criteria we have today may be enough for our stakeholders to say
> "yeah, this is good enough, we'll use it", but might not be good enough to
> ensure ongoing trouble-free support.
>
> I'd like to see some acceptance criteria regarding making sure we can
> continue to evolve and support this code well into the future. For me, that
> means: don't duplicate code, have tests, define and adhere to standards
> across our services. Perhaps some of the consternation my proposal has
> given rise to is due to the fact that these concerns aren't codified in
> acceptance criteria?
>
> How does one word such an acceptance criteria? Isn't this a sort of cheat,
> given that our stakeholders haven't asked for this?
>
>

Yes, it is a cheat. Stakeholders do not care about *the code*, it's just
our 'instrument' to provide them value. Strictly speaking we should only
care about *the code* when it is affecting the how we deliver value, either
reducing our velocity (which is your _valid_ point) or prevent us to solve
problems.

Implementing it using language X or Y, framework A or B, we should pick
what is best for us, what helps us to deliver the requested values as fast
as possible. We did that and will be continuously improving the way we do.

Apologies in advance if it sounds rude and unremarkable, but nobody is
approaching us asking for *beautiful code*, they want solutions, as fast as
we can provide them.

Regarding supporting the solutions we create, microservices
recommendations, when followed, offers us more feasible alternatives than
"only release near-perfect code, otherwise there will be trouble". Nothing
necessarily wrong in being defensive, but it not only costs time (which is
very rare these days) but also hasn't been entirely efficient in preventing
"trouble" in such dynamic and rapid-changing cloud production environments.

As long as services are isolated and highly specialised (which results in
small independent parts) and we are capable of monitoring its behaviour
very accurately in production, If it works, "supporting" means "do nothing"
and when something goes wrong it can literally be "delete it and write a
new one with everything good you have learned since you it was released".

It is supposed to be an always-forward path, even if we did something wrong
in the past, no amends, put something new in its place.



> <snip>
>
>
>>> 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.
>>>
>>
>> If that's opaque, then let's make it clear. Let's raise such things and
>> solve them, CD is a *team's* problem, if that's not what it looks like then
>> we should fix it. :)
>>
>>
> Yes please. I'd love to know how our CD system is supposed to work. In
> particular, I'm not sure of a few points:
>
>  * How should CD interact with the development cycle? phrased differently:
> as a developer, how do I get told that the thing I just proposed for
> merging is horribly busted and doesn't deploy cleanly?
>  * How should CD interact with ops? How should we be notified of some
> runtime issue? How does CD learn about runtime issues?
>  * How will CD serialise and handle multiple upgrades? for example: what
> happens if we need to roll out component_A and component_B in an atomic
> operation? What should it do if component_A has several revisions that can
> be deployed - deploy them all at once, or deploy them one at a time?
>
> Perhaps we need to answer these questions in the normal scrum sprint
> process (i.e.- actually plan it as a story, so we know what we're aiming
> for)? Maybe I'm missing something, but a CD solution that does what we want
> seems like a far more difficult and complex task than actually building
> these services (maybe we need a sprint for the CD alone?).
>
> I'm aware that we ought to be favouring 'working software over
> comprehensive documentation', but I think that in this case a bit of
> planning and documentation would make this product a lot clearer.
>
>
Those are very good points about our CI-CD requirements and I am already
satisfied because they finally emerged.

CI-CD (highly automated, instrumented and monitored production environment)
is a very important aspect of the way we intend to deliver and maintain
solutions and was entirely overlooked for one and half sprint.

I will try to extract the ideas, arguments and questions from this thread
and the spread documents we have around and consolidate them all in the
Design Document for this sprint.

This way the whole plan can be reviewed, debated and finally implemented.
We will be allowed to say a lot of things about it, except ignore its
existence and need.

[huge snip]

[]

-- 
Celso Providelo
celso.providelo@xxxxxxxxxxxxx