Help! No development infrastructure in company! I've been tasked to implement it!

Question

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.

Answer 1

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.

Answer 2

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.