[Cialug] Release Management

[Matthew Nuzum]

I totally understand that the ideal and reality are often at odds.

There is a saying I've heard over the years from multiple sources, (so it
must be true) "If a process is painful, you need to do it more often."

The worst processes are those ones that you do just frequently enough that
by the time comes around to do it again, you've forgotten the tricks for
making it smooth. (from your example, the "oh, that didn't work, then...")

For those types of tasks, the next best thing to automation is
documentation. Does your team have a wiki-like tool that's easy for them to
update? This kind of project can pay for itself big time. Github and
Bitbucket are great cloud solutions, Gitolite and Trac are great
self-hosted solutions, and all provide version control integration, task
management and wiki-like documentation. Mediawiki and Moin Moin are great
wikis if that's all you need. Sharepoint will work in a pinch, if that is
lower friction.

At Deere we have a lot of processes that just can't be automated easily
because they involve coordinated efforts of numerous people. For those
cases we recently started using a wiki for documentation. It's been helpful
for unlocking information that we've been storing in people's heads.



On Fri, Aug 22, 2014 at 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
>



-- 
Matthew Nuzum
newz2000 on freenode, skype, linkedin and twitter

♫ You're never fully dressed without a smile! ♫