Advice for dev/testing server

[Hammer, Erich F]

In my (admittedly limited) experience with serving web applications, there has been a production server ("prod") and a development server ("dev"). Since the applications have always been only managed by us (i.e. "out of the box") and not actually developed, the dev server has been essentially a staging area for the next version of the application. It's where we can connect it to other "dev" systems and poke at it to see what settings need adjusted (on the updated app or others) before rolling the upgrade to production.

The problem I'm facing is I have a high-energy, high-ambition, self-described developer (of dubious skill and not under my management) who wants to make code changes and other adjustments on an open source web application that services his department. He does not currently have access to the dev server itself (only the application interface), but is insisting he needs it so he can test his work. Complicating this is that due to arrangements outside my control, server access = admin access. If he is allowed on, I have no way to restrict his actions (although the server doesn't serve anything else). This application server pair was our first step in getting some control over his current web of duct tape, popsicle sticks, and custom code (all poorly documented) that holds together all the various things his department "needs". Apparently he was doing this with the previous application systems, but we didn't learn about that until recently (did I mention poor documentation?).

My question is about "best practice" for application development and testing... Although the name would imply it, is it normal to go "hog wild" on a development server? Should we have another server in place to allow us to have independent pre-production testing (like now) and "big change" development (as our "developer" is asking)? Am I being too cautious here? How is this supposed to work?

Thanks,
Erich


--
Erich Hammer Head of Library Systems
er...@albany.edu University Libraries
518-442-3891 University @ Albany

"If we don't believe in freedom of expression for
people we despise, we don't believe in it at all."
-- Noam Chomsky

[Michael B. Smith]

In situations like yours, I recommend three tiers.

Dev, QA, Prod.

Give him a dev server and let him do "whatever he wants". In fact, if he's running Win10, he can install IIS (or with WSL, apache and/or nginx) and do 95% of everything right there.

What you currently have as dev becomes QA. Require documentation so that Ops can promote from dev to QA and from QA to Prod. If it doesn't work, kick it back.

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/MN2PR04MB55510FDC00F9A735E8F5BA60CCAD0%40MN2PR04MB5551.namprd04.prod.outlook.com.

[Henry Awad]

Let me preface by saying that I'm not a developer but here are my recommendations:

You need to use some sort of code management server like GitLab (which is free https://about.gitlab.com/stages-devops-lifecycle/). This is the best way to be able to manage code changes and be able to revert back. 

If implementing source code management server is not an option, then having a tracking log of changes on your server would become essential. I don't have any recommendations for a specific tool but there are many (not sure if there are any free ones available). I also agree with Michael about having a three-tier server hierarchy: Dev, UAT or QA, and Prod. Finally, a good backup (or snapshot if VM) that you can revert back changes quickly and easily should be in place.

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/MN2PR04MB55510FDC00F9A735E8F5BA60CCAD0%40MN2PR04MB5551.namprd04.prod.outlook.com.

--

Henry Awad

Systems Engineer III

Technology Services

The Catholic University of America

[CESAR. A]

I run similar concepts. 

Environments: sandbox (open) -> DEV (infra an sec restrictions) -> PROD

Requirements, knowledge and docs: 0-40 - > 60-80 - > 90+ %

With prod locked down and change management team approving changes and others doing the implementation and changes in most instances (verifies docs). Preprod runs in dev environments for UAT. 

Sandbox runs in azure with their bosses getting the bill. 

Cesar A

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2967c99da5fc4cb9b706cb40554b7545%40smithcons.com.

[Hammer, Erich F]

Thanks for the response. He does use a Git repository, so that is good. My concern is that he won't be limited to code changes (because of the Admin rights), and he is the type to tweak and adjust all kinds of other things that could break the system in ways we can only back out of by a restore (which is in someone else's hands unfortunately).



On Wednesday, April 29, 2020 at 09:44, Henry Awad eloquently inscribed:

> <mailto:er...@albany.edu> University Libraries 518-442-3891

> University @ Albany
>
> "If we don't believe in freedom of expression for
> people we despise, we don't believe in it at all."
> -- Noam Chomsky
>
> -- You received this message because you are subscribed to the Google
> Groups "ntsysadmin" group. To unsubscribe from this group and stop
> receiving emails from it, send an email to
> ntsysadmin+...@googlegroups.com

> <mailto:ntsysadmin%2Bunsu...@googlegroups.com> . To view this

[Philip Elder]

We have one of those at one client site. No concept of self-responsibility either.

Took out the entire mail setup among other things by deleting "superfluous" DNS entries at the DNS host. :P

Nothing to see there ...

Microsoft High Availability MVP
E-mail: Phili...@mpecsinc.ca
Phone: (780) 458-2028
www.CommodityClusters.Com
Blog Site
Twitter: MPECSInc
Skype: MPECS Inc.

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

-----Original Message-----
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Hammer, Erich F
Sent: April 29, 2020 8:19 AM
To: ntsys...@googlegroups.com
Subject: RE: [ntsysadmin] Advice for dev/testing server

Thanks for the response. He does use a Git repository, so that is good. My concern is that he won't be limited to code changes (because of the Admin rights), and he is the type to tweak and adjust all kinds of other things that could break the system in ways we can only back out of by a restore (which is in someone else's hands unfortunately).



On Wednesday, April 29, 2020 at 09:44, Henry Awad eloquently inscribed:

> Let me preface by saying that I'm not a developer but here are my
> recommendations: You need to use some sort of code management server
> like GitLab (which is free

> https://urldefense.proofpoint.com/v2/url?u=https-3A__about.gitlab.com_
> stages-2Ddevops-2Dlifecycle_&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5
> A_CdpgnVfiiMM&r=zmFHnDgK5Hyu7-iaPoMa6lewGQK356Tjsmbz10qYxNU&m=AN8tt_IT
> 9ncCydGt9aPpzVZ1f8OmXNUSCO0WNK7jS4U&s=CtSxDqg2x1f8cOwJlZ6Itd_fioa6MAKz
> QbLO2M1MauA&e=). This is the best way to be able to manage code

> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com
> _d_msgid_ntsysadmin_MN2PR04MB55510FDC00F&d=DwIFaQ&c=euGZstcaTDllvimEN8
> b7jXrwqOf-v5A_CdpgnVfiiMM&r=zmFHnDgK5Hyu7-iaPoMa6lewGQK356Tjsmbz10qYxN
> U&m=AN8tt_IT9ncCydGt9aPpzVZ1f8OmXNUSCO0WNK7jS4U&s=8dSooY2zwv9_N7thi4sQ
> JHCpgQQcms5XBa4IXege75Y&e=
> 9A735E8F5BA60CCAD0%40MN2PR04MB5551.namprd04.prod.outlook.com.

>
>
>
>


--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_ntsysadmin_MN2PR04MB55512BAA00AFAD9A982DA8E9CCAD0-2540MN2PR04MB5551.namprd04.prod.outlook.com&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=zmFHnDgK5Hyu7-iaPoMa6lewGQK356Tjsmbz10qYxNU&m=AN8tt_IT9ncCydGt9aPpzVZ1f8OmXNUSCO0WNK7jS4U&s=Z-MF18zSg21HQsp7D-s07BdNtYAdtRoJ1BRKl_Eyn3w&e=.

[Henry Awad]

Yes, I have worked at many places where there was at least one rogue IT staff member (not always a programmer or developer). They're always fun to work with and require a lot of meditation, Xanax, alcohol, or whatever else works to not pull a Homer Simpson choke hold. The worst part is when they are in management and you cannot complain about it to your manager. I'm sure that everyone on this list has endured similar stress and aggravation. 

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/a39f041e9ca84337be1d04883ba5f3bd%40MPECSInc.Ca.

[Jim Kennedy]

I am now running a team of 19 Devs.

They ALL have everything they need on their local workstations to run anything we work on. Full builds, servers whatever they need all running on VM's. That is their development playground/workspace. When they are ready to go to BETA they go to what we call our development system. Which is a stand alone system for our software that is run just like it belongs to a customer where we do further evaluation and fine tuning.

You can build that for him with a VM/Hyper server if you don't want to give him that powerful of a workstation...for cost reasons. But what ever that first system is, yes they have full admin/control over all of it. They need that.

So call it what you want but it is three systems. Local Dev, BETA Dev then Prod.

-----Original Message-----
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Hammer, Erich F

Sent: Wednesday, April 29, 2020 9:27 AM
To: ntsys...@googlegroups.com

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/MN2PR04MB55510FDC00F9A735E8F5BA60CCAD0%40MN2PR04MB5551.namprd04.prod.outlook.com.

[Robert ECEO Townley]

DevOps is coming.  

There are various automated testing tools that could be implemented.  

Write down a list of basic tests and have them implemented ( AutoIT and that other Auto?,  selenium, powershell, and others the names of which escape me) and demand proof  they are passing on both the dev and QA servers.   Much of it can be automated and has to be.   Demand it has to be automated.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/MN2PR11MB38211B42304BFCA89DBA886CF6AD0%40MN2PR11MB3821.namprd11.prod.outlook.com.

[Jim Kennedy]

Good advice, and we are doing that currently……a blending of both for now.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CACE8FwnEC9Qokkyw9nZCKKrkUPKiyOn2u6i32zm3%2BQbR8hh%2BgA%40mail.gmail.com.

[Henry Awad]

I would also add that having a change control and service management (ITSM) mechanismS in place helps to document the what, when, where, and who of changes being made. So your dev team will have to present the changes they are making and have them approved before deployment into your production environment. Of course that won't stop a "rogue" developer from messing up the dev and QA environments but at least it protects your production.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CACE8FwnEC9Qokkyw9nZCKKrkUPKiyOn2u6i32zm3%2BQbR8hh%2BgA%40mail.gmail.com.

[Kurt Buff - GSEC, GCIH]

Traditionally (from my days working at an IBM mainframe helpdesk, back
in the late '80s), there were 4 stages of deployment: Dev, Test,
Staging, Production.

Devs worked in Dev, and rolled code to Test
QA worked in test and rolled code to Staging
Sysadmins validated the code in Staging and rolled code to Prod

Devs could only modify code in Dev, and couldn't modify anything at later stages
QA couldn't modify code, and could only test, and once passed, could
only roll code to Staging
Sysadmins validated function in Staging, which was kept exactly in
sync with Prod, and couldn't modify code, and once validated would
roll to Prod once validated

This was a larger environment than you're likely to have, but probably
the biggest thing is to make sure that the dev cannot, under any
circumstances, touch either Test or Prod, except as an ordinary
consumer. Dev is not test, nor a Sysadmin, and should have no place in
updating anything in either environment.

DevOps is a mistake - to fail fast means to fail. By all means
automate as much as you can, but nothing so far beats the Mark I
eyeball and brain in the chair and at the keyboard.

Kurt