What every DevOps adoption project needs - minimum

Context: You've asked an external company to help you work in a more DevOps like fashion. Both stakeholders want to succeed. The external company will always need the following things from you regardless of industry or project.

This is the checklist:

• A short explanation of all of the code repositories, links to them and their names
• Key contacts
• Access granted to all code repositories so the external org can do their work
• Explanation of current deployment process (document)
• Explanation of how a developer currently runs the project locally, if relevant

A short explanation of all of the code repositories

Deliverable: A short one page document with links and names of the repos and brief sentence on what each repo is for. Is is a failure to not include links to the repos.

Your internal organisation knows the naming conventions and structure of repositories. The external org does not. Some organisations only have one large mono-repo, others have tens to hundreds of repos.

Key contacts

Deliverable: Document listing people who are contactable, with their contact information and, critically, which parts of the organization/software/product they are most familiar with.

Access granted to all code repositories

Deliverable: External organisation to provide names/usernames/emails required to have access. Internal organisation to grant access to all of the repos.

For example, access to the Git repos (github, bitbucket, gitlab).

Access granted to cloud/hosting services used

Deliverable: Access granted to cloud and/or hosting provider being used to the members of the external org who need access.

Access to whereever the application/service/product gets deployed.

This might be multiple IAM Role (AWS) or a GCP  Role (Google Cloud), given to the external orgs developers, or simply adding email addresses required to the on premise hosting account used by the org.

Explanation of current deployment process

Deliverable:  A document detailing the current steps taken to release a new version of the service/product/software, including associated documents. This must be a document that can be followed by another person without needing to contact.

Bad example: "Person x deploys it manually"
Good example: (A document detailing the steps person x performs, and associated reference documentation).

Purpose: This helps the external organisation understand where your current at, and where they can help you.

Explanation of how a developer currently runs the project locally, if relevant

Deliverable: A document details the steps your developer(s) take to run your software/project/service manually.

This will save many hours (possibly weeks) back and forth between an internal/external organisation.

Help! I don't have any of these documents, what do I do?

That's ok! Use the above list to get started. Everyone benefits.