canonical-ci-engineering team mailing list archive

[Joe Talbott <joe.talbott@xxxxxxxxxxxxx>]

On Thu, Apr 02, 2015 at 01:03:06PM +1300, Thomi Richards wrote:
> Hi,
> 
> I mostly agree with you, so I'm trimming some of your mail to just the bits
> I have comments for:
> 

Likewise.

<snip>

> 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 tend to agree that the CD story is growing complex and hearkens back to
deploy.py.  I haven't been able to wrap my mind around the details
enough to be able add much further to the conversation.  I would however
hazard to guess that we'd be best served to do manual deployments
including things like upgrades (i.e. old version deployed and new
version deployed), service failures, major regressions, etc.

I have really come to like our mindset that we'll address things when
they happen rather than trying to plan for them in advance without any
degree of certainty.  Of course we should plan for some things like
maintainability and clarity.  The copy-and-paste approach we've adopted
for these services has chaffed my sensibilities as a software engineer
but I can see the utility in not burdening ourselves with the, however
small, complexity of factoring out common code and ensuring that it
functions adequately for all consumers.

Even in writing this I find myself unable to choose a side in the
debate. Sorry for the indecisiveness.

<snip>

> 
> FWIW, I'm enjoying the work we're doing. micro-services are a new concept
> to us all, I guess, so there's bound to be some ... teething problems. On
> the whole I think we're doing about as well as we could reasonably expect
> at this point. I'm also enjoying this discussion, since it gives us a
> chance to discuss our sprint planning before the retrospective.

I agree and I'm glad we're having these discussions.

Cheers,
Joe