[Cialug] Release Management

[c]

Do you have a daily standup or anything where you can call someone out for
passing bad code multiple times?

Normally if someone passes shit code to QA regularly then you talk to their
tech lead and have them read them the riot act.
On Aug 22, 2014 7:12 PM, "Todd Walton" <tdwalton at gmail.com> wrote:

> All good suggestions, thank you.  I think the automated tools are not in
> our near future.  But I know that when I was on the other side of this
> equation, I would have loved to have a button to push that pulls code and
> settings from production and installs it in dev.
>
> Right now I'm just trying to get a process in place, absent handy tech.  I
> think a primary feature of such a process should be that there's some
> minimal cost to the developer to pushing his or her code to QA, so that it
> doesn't become "oh that didn't work? here, push this and try it out.  no?
>  okay what about this?".  It should work in dev before moving to QA.
>
> --
> Todd
>
>
>
> On Fri, Aug 22, 2014 at 12:26 PM, Matthew Nuzum <newz at bearfruit.org>
> wrote:
>
> > I agree with Purcell. What he describes is what I've observed to be best
> > case, with close second to have an Openstack cloud that they can easily
> > publish to.
> >
> > One thing I'd suggest doing is that developers have an automated tool to
> > pull data from production and in the process sanitize customer data so
> > that, for example, e-mail addresses and passwords at the minimum, are
> > replaced.
> >
> > Life for developers is so much easier if, with the push of a button, they
> > can test their app on a clean local or remote virtual machine that
> operates
> > just like a production environment.
> >
> > With something like this, there may be no need to give devs access to QA
> > since the difference between QA and Dev is often the quality of the data.
> >
> >
> > On Thu, Aug 21, 2014 at 3:14 PM, c <cbpurcell at gmail.com> wrote:
> >
> > > As Jim said. A lot of it is about the tools, but it depends on your
> > > developers' process. If all of your developers have a full virtual
> > > environment on their machine that is a clone of production, and they do
> > all
> > > development there, then you can use tools to keep your environments
> > > separated.
> > >
> > > Ideally your devs do all development on their local virtual machine.
> > >
> > > - Once the Dev has a working fix they check all of that code into
> remote
> > > git/ code versioning.
> > >
> > > - Dev ties that commit into your ticketing system. Through the
> ticketing
> > > system they note that the fix is ready for testing.
> > >
> > > - QA  approves pushing the Devs changes to the QA/testing machines
> > >
> > > - QA either approves fix, or sends back to Dev to update/fix per QA
> > > comments.
> > >
> > > - Once QA approves change, in the ticket and the system schedules the
> > > automated push to production per your rules for regular or emergency
> > > updates.
> > >
> > > --Purcell
> > >
> > > ......
> > > .
> > >
> > > .
> > > ....
> > >  On Aug 21, 2014 10:38 AM, "jim kraai" <jimgkraai at gmail.com> wrote:
> > >
> > > > i've seen it all, i think
> > > >
> > > > isolation is good, if flushes out forgotten steps, assumptions, and
> > > > configuration issues.
> > > >
> > > > a lot of times process comes from tools instead of the other way
> around
> > > >
> > > > jenkins is a good tool for what you've mentioned.  as little or as
> much
> > > of
> > > > the business process of release management can be run from it and it
> > can
> > > be
> > > > a good reference for what's where
> > > >
> > > > --jim
> > > >
> > > >
> > > >
> > > > On Thu, Aug 21, 2014 at 10:12 AM, Todd Walton <tdwalton at gmail.com>
> > > wrote:
> > > >
> > > > > How many of you work at a company with a managed release process
> for
> > > > code?
> > > > > Like, you maintain identical dev/qa/prod servers, and developers
> > write
> > > > code
> > > > > and get it working, then you release it to a testing environment
> and
> > > have
> > > > > users break it, then production when it's ready, etc...  Do you
> have
> > > > > something like that where you work?
> > > > >
> > > > > Where I work we're still sort of developing all that, but the basic
> > > > outline
> > > > > is like I've said above.  However, in the past, developers have
> > > typically
> > > > > had access to not only the dev servers but also the testing
> servers.
> > > > We're
> > > > > now starting to limit that access, so that releasing to testing is
> > just
> > > > > like releasing to production, so you truly have a good test of
> > whether
> > > > the
> > > > > code is good or not.
> > > > >
> > > > > I'm considering whether or not developers should be able to push
> > their
> > > > own
> > > > > code to testing, but still restrict their access to the testing
> > > servers.
> > > > > Like, some automated button they can push that takes dev and puts
> it
> > in
> > > > > qa/test, but they can't go and fiddle with server settings.
> > > > >
> > > > > --
> > > > > Todd
> > > > > _______________________________________________
> > > > > Cialug mailing list
> > > > > Cialug at cialug.org
> > > > > http://cialug.org/mailman/listinfo/cialug
> > > > >
> > > > _______________________________________________
> > > > Cialug mailing list
> > > > Cialug at cialug.org
> > > > http://cialug.org/mailman/listinfo/cialug
> > > >
> > > _______________________________________________
> > > Cialug mailing list
> > > Cialug at cialug.org
> > > http://cialug.org/mailman/listinfo/cialug
> > >
> >
> >
> >
> > --
> > Matthew Nuzum
> > newz2000 on freenode, skype, linkedin and twitter
> >
> > ♫ You're never fully dressed without a smile! ♫
> > _______________________________________________
> > Cialug mailing list
> > Cialug at cialug.org
> > http://cialug.org/mailman/listinfo/cialug
> >
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
>