Answers: <blockquote>
    <p>Have you been in this scenario before? </p>
  </blockquote>
  
  <p>Yes. Pretty standard scenario in my experience.</p>
  
  <blockquote>
    <p>How did you address and overcome these obstacles? </p>
  </blockquote>
  
  <p>In very small steps.</p>
  
  <blockquote>
    <p>How long did it take to implement? (as a rough idea)</p>
  </blockquote>
  
  <p>Very long; in one rather large extreme case: over 10 years, and still ongoing.</p>
  
  <blockquote>
    <p>How would you prioritize the tasks listed above?</p>
  </blockquote>
  
  <p>My priority, with additional comments:</p>
  
  <ul>
  <li>Throw all active projects into source control.
  
  <ul>
  <li>This should really be a no-brainer and low-hanging fruit.</li>
  </ul></li>
  <li>Implement coding standards.
  
  <ul>
  <li>Sensibly.</li>
  </ul></li>
  <li>Introduce a methodology more suited to how the team currently operates, most likely Agile or Scrum and the tools and documentation templates that go with it.
  
  <ul>
  <li>If there is no methodology at all right now, then I'd start with a very lenient Kanban first - which basically just means throw up a ticket system and keep track of everything relentlessly. I would hold off with full-fledged Scrum until everything is on track and you're established as a Good Guy.</li>
  </ul></li>
  <li>Implement staging so that we have Dev, QA, UAT and Live.
  
  <ul>
  <li>With this goes more separation; i.e. devs need to be weaned off of the production systems. </li>
  </ul></li>
  <li>Introduce tooling and setup training for development team.
  
  <ul>
  <li>Try to have the teams develop their own tools if at all possible.</li>
  </ul></li>
  <li>Implement CI/CD</li>
  <li>Bring all projects up to using the same technologies.
  
  <ul>
  <li>Might just not be feasible, if by technologies you mean languages and libraries. If you mean Docker or OpenShift or whatever, then sure.</li>
  </ul></li>
  </ul>
  
  <p>The most important tip for you from my experience: avoid, at all cost, to do everything yourself. Give "impulses" to the teams, but they have to do it (whatever "it" is) themselves. If you do all the work (either personally, or with your separate "DevOps team"), then you will, at the end of the day, not gain that much as everybody will just depend on you constantly.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-06-04T12:10:55.103Z
Answers: I disagree with the " devs need to be weaned off of the production systems.", they should stay in production (or that's just creating silos where Devops's is about breaking them), but they have to learn to test before going live and still maintain the production part to not forget how it is in prod.
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2018-06-04T18:53:19.013Z
Answers: If I understood correctly, they are developing *on* the production systems now. That has to stop...
Answers: AnoE
Answers: CC BY-SA 4.0
Answers: 2018-06-04T19:58:43.583Z
Answers: Yes, that doesn't mean they should stop touching the production system which your 'weaned off' seems to imply, it should probably be reworded to 'devs need to stop developing on live prod', which mostly is a direct consequence of introducing a staging env, this sentence doesn't convey the right message IMHO
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2018-06-03T21:57:41.360Z
Answers: 2018-06-03T21:57:41.360Z
Answers: AnoE
Answers: <p>I'd prioritize things like this:</p>
  
  <ol>
  <li><p>put all projects in version control</p></li>
  <li><p>automate the builds and immediately/simultaneously bring up CI with those builds - this is important to prevent the teams not yet used with version control from falling into the branching nightmare trap - they will start appreciating the CI fast feedback, even if just for the build portion, they'll start gaining confidence into all these upcoming changes which could be quite scary for them</p></li>
  <li><p>create at least one staging environment, automate deployments to it, start building/growing automated testing and hook them all up to the CI system - now they'll have fast feedback including testing</p></li>
  </ol>
  
  <p>I consider the above absolutely necessary to still be able to maintain the current projects without draining all resources on it, before considering other tools/technology changes, building the rest of the CI/CD pipeline, going into re-works, bring agile into the picture, etc.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-06-04T03:54:33.493Z
Answers: 2018-06-04T03:54:33.493Z
Answers: Dan Cornilescu
Body: <p><strong>Background:</strong>
  I've recently started at a company and I've bee tasked to essentially modernize the development team/dept. Currently the problems are:</p>
  
  <ul>
  <li>Developers currently develop on a live site.</li>
  <li>Sites are backed up but they have no source control.</li>
  <li>No staging process (dev, QA, UAT, live).</li>
  <li>No automated build process.</li>
  <li>No SDLC.</li>
  <li>Minimal (if any) documentation.</li>
  <li>Sites use different technologies.</li>
  <li>Timelines are insane because of huge development delays.</li>
  <li>Development team aren't aware of common tools that can assist with debugging/development.</li>
  </ul>
  
  <p><strong>The plan</strong>
  My thoughts so far are (in no specific order):</p>
  
  <ul>
  <li><p>Bring all projects up to using the same technologies.</p></li>
  <li><p>Throw all active projects into source control.</p></li>
  <li><p>Implement staging so that we have Dev, QA, UAT and Live.</p></li>
  <li><p>Implement CI/CD</p></li>
  <li><p>Introduce tooling and setup training for development team.</p></li>
  <li><p>Implement coding standards.</p></li>
  <li><p>Introduce a methodology more suited to how the team currently operates, most likely Agile or Scrum and the tools and documentation templates that go with it.</p></li>
  </ul>
  
  <p><strong>The Questions</strong></p>
  
  <ul>
  <li><p>Have you been in this scenario before? How did you address and overcome these obstacles? How long did it take to implement? (as a rough idea)</p></li>
  <li><p>How would you prioritize the tasks listed above?</p></li>
  <li><p>What would you recommend I look into/research? (I'm particularly interested in terms of CI/CD and just how to negotiate such a huge task)</p></li>
  </ul>
  
  <p>I feel like I need a kind of Maslow's hierarchy of needs to get more of an idea of where/how to start and what to build up to.</p>
  
  <p><strong>Closing notes</strong>
  Any resources, links, just a pooling of materials, etc. would be greatly appreciated.</p>
  
  <p>Sorry - I know this could be considered a vague question and would give an opinionated response but that would provide the most benefit to me since if I knew exactly the right questions to ask I wouldn't need help because I could use a search engine.</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-06-03T21:32:13.783Z
Comments: Have you thought of using the public cloud managed services?  you did not elaborate on what do you have already in terms of infrastructure and operations?
Comments: Walid
Comments: CC BY-SA 4.0
Comments: 2018-06-04T03:10:30.190Z
Comments: @Walid I have suggested the use of cloud managed services but the company doesn't trust the cloud and appears to be pretty scared of it. For the moment I haven't tried anything, I've been querying, poking and prodding with suggestions and asking for clarity to get an idea of what authority/levity I've been given and what has been tried in the past. Currently dev's work on live sites and there's no SDLC at all.
Comments: HQ216493
Tags: <methodology><startup>
Title: Help! No development infrastructure in company! I've been tasked to implement it!
UserDisplayName: HQ216493
ThreadText: # Help! No development infrastructure in company! I've been tasked to implement it!
  
  (Asked by: username_0 on 2018-06-03)
  
  **Background:**
  I've recently started at a company and I've bee tasked to essentially modernize the development team/dept. Currently the problems are:
  
  * Developers currently develop on a live site.
  * Sites are backed up but they have no source control.
  * No staging process (dev, QA, UAT, live).
  * No automated build process.
  * No SDLC.
  * Minimal (if any) documentation.
  * Sites use different technologies.
  * Timelines are insane because of huge development delays.
  * Development team aren't aware of common tools that can assist with debugging/development.
  
  **The plan**
  My thoughts so far are (in no specific order):
  
  * Bring all projects up to using the same technologies.
  * Throw all active projects into source control.
  * Implement staging so that we have Dev, QA, UAT and Live.
  * Implement CI/CD
  * Introduce tooling and setup training for development team.
  * Implement coding standards.
  * Introduce a methodology more suited to how the team currently operates, most likely Agile or Scrum and the tools and documentation templates that go with it.
  
  **The Questions**
  
  * Have you been in this scenario before? How did you address and overcome these obstacles? How long did it take to implement? (as a rough idea)
  * How would you prioritize the tasks listed above?
  * What would you recommend I look into/research? (I'm particularly interested in terms of CI/CD and just how to negotiate such a huge task)
  
  I feel like I need a kind of Maslow's hierarchy of needs to get more of an idea of where/how to start and what to build up to.
  
  **Closing notes**
  Any resources, links, just a pooling of materials, etc. would be greatly appreciated.
  
  Sorry - I know this could be considered a vague question and would give an opinionated response but that would provide the most benefit to me since if I knew exactly the right questions to ask I wouldn't need help because I could use a search engine.
  
  **Tags:** methodology, startup
  
  > **Comments:**
  > **username_1**: Have you thought of using the public cloud managed services?  you did not elaborate on what do you have already in terms of infrastructure and operations?  
  > **username_0**: @username_1 I have suggested the use of cloud managed services but the company doesn't trust the cloud and appears to be pretty scared of it. For the moment I haven't tried anything, I've been querying, poking and prodding with suggestions and asking for clarity to get an idea of what authority/levity I've been given and what has been tried in the past. Currently dev's work on live sites and there's no SDLC at all.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-06-03. Score: 4 | Accepted answer
  
  > Have you been in this scenario before?
  
  Yes. Pretty standard scenario in my experience.
  
  > How did you address and overcome these obstacles?
  
  In very small steps.
  
  > How long did it take to implement? (as a rough idea)
  
  Very long; in one rather large extreme case: over 10 years, and still ongoing.
  
  > How would you prioritize the tasks listed above?
  
  My priority, with additional comments:
  
  * Throw all active projects into source control.
    + This should really be a no-brainer and low-hanging fruit.
  * Implement coding standards.
    + Sensibly.
  * Introduce a methodology more suited to how the team currently operates, most likely Agile or Scrum and the tools and documentation templates that go with it.
    + If there is no methodology at all right now, then I'd start with a very lenient Kanban first - which basically just means throw up a ticket system and keep track of everything relentlessly. I would hold off with full-fledged Scrum until everything is on track and you're established as a Good Guy.
  * Implement staging so that we have Dev, QA, UAT and Live.
    + With this goes more separation; i.e. devs need to be weaned off of the production systems.
  * Introduce tooling and setup training for development team.
    + Try to have the teams develop their own tools if at all possible.
  * Implement CI/CD
  * Bring all projects up to using the same technologies.
    + Might just not be feasible, if by technologies you mean languages and libraries. If you mean Docker or OpenShift or whatever, then sure.
  
  The most important tip for you from my experience: avoid, at all cost, to do everything yourself. Give "impulses" to the teams, but they have to do it (whatever "it" is) themselves. If you do all the work (either personally, or with your separate "DevOps team"), then you will, at the end of the day, not gain that much as everybody will just depend on you constantly.
  
  > **Comments:**
  > **username_3**: I disagree with the " devs need to be weaned off of the production systems.", they should stay in production (or that's just creating silos where Devops's is about breaking them), but they have to learn to test before going live and still maintain the production part to not forget how it is in prod.  
  > **username_2**: If I understood correctly, they are developing *on* the production systems now. That has to stop...  
  > **username_3**: Yes, that doesn't mean they should stop touching the production system which your 'weaned off' seems to imply, it should probably be reworded to 'devs need to stop developing on live prod', which mostly is a direct consequence of introducing a staging env, this sentence doesn't convey the right message IMHO  
  
  ---
  
  ### Answer by username_4 on 2018-06-04. Score: 1
  
  I'd prioritize things like this:
  
  1. put all projects in version control
  2. automate the builds and immediately/simultaneously bring up CI with those builds - this is important to prevent the teams not yet used with version control from falling into the branching nightmare trap - they will start appreciating the CI fast feedback, even if just for the build portion, they'll start gaining confidence into all these upcoming changes which could be quite scary for them
  3. create at least one staging environment, automate deployments to it, start building/growing automated testing and hook them all up to the CI system - now they'll have fast feedback including testing
  
  I consider the above absolutely necessary to still be able to maintain the current projects without draining all resources on it, before considering other tools/technology changes, building the rest of the CI/CD pipeline, going into re-works, bring agile into the picture, etc.
  
  
  ---
  
  