Hi Curtis,
It is an awesome info and process, I have a long way to catch up
Thanks
-Dan
On Sun, May 31, 2015 at 2:36 AM, Curtis Rueden <ctrue...@wisc.edu> wrote:
> Hi Dan,
>
> > PS. Would love to hear other experiences from community rather me
> > sucking out Mirko's :-)
>
> Not sure how relevant my scenario is, but here goes:
>
> My group consists of an international collaboration of OSS developers at
> universities etc., rather than a company. But a lot of our needs are the
> same.
>
> - We have 2-3 core "DevOps" who maintain our Maven architecture
> ("corporate" POM [1] etc.), with several others in the community who have
> been trained enough on how things work to understand and occasionally
> contribute to it.
>
> - The projects encompass several GitHub orgs, each of which has its own
> primary maintainer(s) who at least understand how their Maven POM hierarchy
> works.
>
> - We have Jenkins jobs for everything. http://jenkins.imagej.net/
>
> - We use Nexus to manage our Maven artifacts. http://maven.imagej.net/
>
> > - is java skill set to develop plugin a must?
>
> No, although it is occasionally useful. I think knowing Java can make you a
> better Maven community member though because you can contribute bug-fixes
> to the plugins you find useful. E.g., we use license-maven-plugin, but it
> wouldn't have behaved the way we needed if I hadn't helped it get patched
> upstream.
>
> > - do you have a team or just a few of deep understanding of Maven
> developers?
>
> 2-3 with "deep" understanding and several others worldwide with "moderate"
> understanding has been sufficient for us. And a whole community with next
> to no understanding of Maven, for whom things "just work" in their IDE of
> choice.
>
> > - will a none java RelEng able to perform Maven release?
>
> I don't see why not, although in my scenario everyone who knows about Maven
> also knows about Java. So for us it is the converse: lots of Java
> developers who know little about Maven but want to do their own releases.
> And the beauty of it is: they can! http://imagej.net/Releases
>
> > - does your RelEng maintains the pom or developers?
>
> My group has no dedicated RelEng—just two core developers who also wear the
> RelEng hat among many others. In practice, for the most part, the same
> people who ultimately maintain the most root-level POMs also end up doing
> the releases of the most root-level software projects.
>
> > - what are your challenges?
>
> Maven makes it possible for a small number of developers to maintain 300+
> Git repositories. This is a two edged sword, though: Maven only solves the
> project management side of things, not the other aspects (software
> design/architecture, coding of new features, community support, etc.).
>
> It is important to note that there are many project management challenges
> that Maven makes easier to solve but does not itself fully solve in a
> turn-key way. In particular, continuous integration (thank you Jenkins!)
> and versioning (we use SemVer and carefully managed BOMs) spring to mind.
>
> Since everything we do is OSS, if you care you can read about it yourself:
>
> http://imagej.net/Architecture
> http://imagej.net/Governance
>
> Regards,
> Curtis
>
> On Sun, May 31, 2015 at 4:06 AM, Dan Tran <dant...@gmail.com> wrote:
>
> > Hi Mirko,
> >
> > Looks like the topic getting very interesting here, but I would like to
> > refocus on the skillset
> >
> > How did you form up your team?, did you all pickup Java before joining
> this
> > devops team?
> >
> > Thanks for all the sharing
> >
> > -Dan
> >
> > PS. Would love to hear other experiences from community rather me
> sucking
> > out Mirko's :-)
> >
> >
> > On Sun, May 31, 2015 at 1:03 AM, Mirko Friedenhagen <
> > mfriedenha...@gmail.com
> > > wrote:
> >
> > > Hello Dan,
> > >
> > > we treat tooling like software as well. Ticket creation is an
> automated 2
> > > click process and the package qa will not take more than 5 minutes for
> > > small changes.
> > >
> > > External libraries from central may be used at free will, but we
> > recommend
> > > stuff in a so called toolbox, these dependencies are managed in the
> > > department pom.
> > >
> > > The (programming) architects and we help discovering alternatives in
> our
> > > toolbox, stuff from repositories outside central is mostly put in a
> > > third-party repo in Artifactory.
> > >
> > > Regards
> > > Mirko
> > > --
> > > Sent from my mobile
> > > Am 31.05.2015 00:06 schrieb "Dan Tran" <dant...@gmail.com>:
> > >
> > > > Hi Mirko
> > > >
> > > > Looks like you have Artifactory to store all of release artifacts and
> > > > another 'release' repo to store the final approved release
> > > >
> > > > Is internal tooling, thirdparty upload going thru the same release
> > > > process?
> > > >
> > > > Thanks
> > > >
> > > > -Dan
> > > >
> > > > On Sat, May 30, 2015 at 2:41 PM, Mirko Friedenhagen <
> > > > mfriedenha...@gmail.com
> > > > > wrote:
> > > >
> > > > > Hello Dan,
> > > > >
> > > > > - Every developer may deploy SNAPSHOTs, however this is normally
> done
> > > > > by Jenkins.
> > > > > - We do not enforce staging from Jenkins, however almost all
> projects
> > > > > do this. We do not enforce this, so Jenkins outages do not inhibit
> > > > > releasing hot fixes.
> > > > > - Releases are deployed to a staging repository in Artifactory and
> we
> > > > > have a process called package-qa where for every staged release a
> > > > > corresponding JIRA ticket has to be created with information
> > (changes,
> > > > > Wiki page, diff link since last release, ticket queue). This is a
> > > > > central place where you may see all releases in one place.
> > > > > - This ticket is parsed by a script from Jenkins which procures
> > > > > artifacts from staging to a releases repository and adds general
> > > > > quality information from SonarQube and Jenkins as well as the SHA1
> > > > > sums to the ticket so we have a second record which may be used to
> > > > > detect forgery. Additionally the script checks for the existence of
> > > > > the SCM tag and retrieves the number of changed lines between
> > > > > releases.
> > > > > - No blocker or critical and no new major issues are allowed in
> > > > > SonarQube, otherwise procurement will fail.
> > > > > - The reporter and the "mover" have to be different persons to
> > enforce
> > > > > a "four eyes" principle.
> > > > > - The "mover" (sometimes someone from development QA, most of the
> > > > > times nowadays another developer) has to check some things and must
> > > > > inspect the diff to detect whether all changes are explained.
> > > > > - Our operations teams will only pick production releases from the
> > > > > final releases repository, other stages may pick up artifacts from
> > the
> > > > > staging repository.
> > > > > - We do not sign artifacts.
> > > > >
> > > > > Regards
> > > > > Mirko
> > > > > Regards Mirko
> > > > > --
> > > > > http://illegalstateexception.blogspot.com/
> > > > > https://github.com/mfriedenhagen/ (
> http://osrc.dfm.io/mfriedenhagen)
> > > > > https://bitbucket.org/mfriedenhagen/
> > > > >
> > > > >
> > > > > On Sat, May 30, 2015 at 7:31 PM, Dan Tran <dant...@gmail.com>
> wrote:
> > > > > > Thanks Mirko
> > > > > >
> > > > > > * What about snapshot and release policy, do developers/qa have
> > > > access
> > > > > to
> > > > > > deploy snapshot and release artifacts?
> > > > > > * do you use artifact signing similar to Maven Central?
> > > > > >
> > > > > >
> > > > > > Thanks again
> > > > > >
> > > > > > -Dan
> > > > > >
> > > > > > On Sat, May 30, 2015 at 9:21 AM, Mirko Friedenhagen <
> > > > > mfriedenha...@gmail.com
> > > > > >> wrote:
> > > > > >
> > > > > >> What I forgot:
> > > > > >>
> > > > > >> patience, social skills and remembering that not every
> > application
> > > > > >> developer needs to be a build specialist are important as well
> :-)
> > > > > >>
> > > > > >> Regards
> > > > > >> Mirko
> > > > > >> --
> > > > > >> Sent from my mobile
> > > > > >> Am 30.05.2015 07:29 schrieb "Dan Tran" <dant...@gmail.com>:
> > > > > >>
> > > > > >> > Hi
> > > > > >> >
> > > > > >> >
> > > > > >> > I would like to ask if the community can share with me what
> it
> > > > takes
> > > > > to
> > > > > >> > maintain an enterprise build system with continuous
> integration
> > of
> > > > > 100+
> > > > > >> > developer + QA and growing using Maven. The build system
> > contains
> > > > > many
> > > > > >> > components with their own release cycle and they do integrate
> > > > > together.
> > > > > >> >
> > > > > >> >
> > > > > >> > - is java skill set to develop plugin a must?
> > > > > >> > - do you have a team or just a few of deep understanding of
> > > Maven
> > > > > >> > developers?
> > > > > >> > - will a none java RelEng able to perform Maven release?
> > > > > >> > - does your RelEng maintains the pom or developers?
> > > > > >> > - what are your challenges?
> > > > > >> >
> > > > > >> > Thanks
> > > > > >> >
> > > > > >> > -Dan
> > > > > >> >
> > > > > >>
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
