<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Following on from what Mike and David has said, we move our products through the release management process between our different grids (development -&gt; QA -&gt; alpha -&gt; beta -&gt; production) using scripts we've written in Puppet. &nbsp;We also script some of our testing (both functional testing, and security testing such as source code analysis and fuzzing).<div><br></div><div>Even tough we use lots of different platforms (including required changes to firewalls and switches) and thousands of server, Puppet works well.</div><div><br></div><div>James</div><div><br><div><div>On 26 Nov 2010, at 11:13, David Halliday wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I'm (in one of my roles) a build&nbsp;manager&nbsp;and Mike is correct. However much management scream and jump around wanting something live yesterday. Testing provides protection from&nbsp;embarrassment.<div><br></div><div>I'm not saying that we always do this properly BUT the more we (the systems and deployments team) have been refusing to send things&nbsp;prematurely&nbsp;live the fewer&nbsp;embarrassing&nbsp;mistakes have been made.</div>
<div><br></div><div>Release management roles like information security roles are vital to a company running&nbsp;professionally. You aren't going to receive thanks very often because most of the world only notices you doing your job when your job is to hold up progress to make sure things are done properly.<br>
<br><div class="gmail_quote">On 26 November 2010 11:07, Mike Evans <span dir="ltr">&lt;<a href="mailto:mike@tandem.f9.co.uk">mike@tandem.f9.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
On 26/11/10 10:32, Dan Attwood wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I was wondering if any one had any tips or tricks on how they set up<br>
their environment to avoid this kind of problem.<br>
<br>
</blockquote></div>
In the environments I've worked at developers - even senior ones - had no access rights from their machines to anything running in the live environment. &nbsp;Deployment to the live and pre-production environments was always through some sort of package management/deployment script. &nbsp;That meant that the Test environment was used to test the actual functionality, the pre-production environment was used to test the package was deployable, and for final User Acceptance Testing and then the change was made to production using the same deployment mechanism as to pre-prod. &nbsp;To run the deployment mechanism you should have a different user - even if it's you with a different hat on, different password etc.<br>
<font color="#888888">
<br>
Mike</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Kent mailing list<br>
<a href="mailto:Kent@mailman.lug.org.uk" target="_blank">Kent@mailman.lug.org.uk</a><br>
<a href="https://mailman.lug.org.uk/mailman/listinfo/kent" target="_blank">https://mailman.lug.org.uk/mailman/listinfo/kent</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>Kent mailing list<br><a href="mailto:Kent@mailman.lug.org.uk">Kent@mailman.lug.org.uk</a><br>https://mailman.lug.org.uk/mailman/listinfo/kent</blockquote></div><br></div></body></html>