areas where we can invest in automation?

[Kevin Fenzi]

On Tue, 28 May 2013 09:45:43 -0400
Ralph Bean <rbean at redhat.com> wrote:

> Some observations/ideas:
> 
> 1) The packager workflow is pretty tedious.  There has been some
>    improvement to it, but more can be done.  Things like
>    fedora-review and fedora-create-review (and bodhi!) are a huge
>    help.  But there are plenty of inefficient "blocking" points in the
>    process.
> 
>    For instance, once a new package is approved, only then does the
>    submitter declare what branches they want with an scm admin
>    request.  They then wait for an scm admin to declare that they
>    have created their branches, and then wait for a cronjob to run
>    that gives them permission to push on those branches (manually).
>    They then wait for their koji builds to finish to (manually) submit
>    bodhi updates.
> 
>    It would be nice if we could automate that whole process -- once a
>    package is approved, if there were a "make-it-so" button that
>    required no further intervention from the packager (but still
>    required the keen eye of an scm admin).

We've talked about this for ages. ;) It was going to be part of a new
pkgdb, then standalone, then in a composedb thing. Not sure where it
is now. ;) 

The scm admin script currently in use is pretty easy... it's usually
that we simply only have one scm admin at a time thats processing
things. :( 
 
>    There are further sequences down the pipeline like requesting that
>    packages in testing be pushed to stable, but there are good
>    arguments against automating that.

To some extent thats already automated with the karma system. ;) 

> 2) Continuous deployment for infrastructure.  It has been tossed
>    around in IRC, possibly at FUDCon as well.  If application
>    developers could "git push" on the develop branch and have those
>    changes automatically roll out to our staging infrastructure --
>    that would save a lot of time.  Packaging our apps, building rpms,
>    signing them, copying them to our infra yum repos, rebuilding those
>    repos, clearing the cache on the target machines, performing a yum
>    update <-- that process is cumbersome.

yeah, but I think of that as more a dev thing than staging. Staging is
something you keep very close to production and only right before you
intend to go to production do you update staging. 

Others might have differing thoughts on that... 

>    I suspect that the "release only when we have accumulated enough
>    changes to warrant enduring the burdensome release process" mode
>    of deployment (as opposed to "release early, release often") also
>    poses somewhat of a barrier to new contributors.  They contribute
>    a patch.. nice!  When does it go live?  When one of our
>    overstretched sysadmin-mains can get around to it (it is required
>    that one of them sign the package).

Yeah. 
 
>    Caveat #2.1:
>    There are some ways around this.  Individuals can get around the
>    requirement of having a sysadmin-main touch their test release by
>    installing their rpm directly on the target machine.  They still
>    have to jump through some hoops to make it happen.
> 
>    Caveat #2.2:
>    This is one of the reasons we put so much work into our private
>    cloud (dev nodes).  There is no barrier there for teams to set up
>    their own continuous deployment mechanism.  This meets most needs,
>    but we don't have a way to iterate rapidly on some of the more
>    important pieces of our infrastructure.  Apps/services that
>    interact with each other don't quite work out on isolated cloud
>    nodes.  The bodhi masher?  Koji?  fedmsg?  mirror manager?  We
>    can't necessarily test those on dev nodes (and some we can't test
>    in staging -- resolving this down the road would save some
>    headaches).

Yeah, something to ponder on for sure. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20130528/9766b1cf/attachment.sig>