Define the Platfoorm that we will be building or augmenting.
Standardize the following details for each project:
- Infrastructure Management and Provisioning
- Security and Secrets Management
- Application Networking (consul, ALB, etc, mesh)
- Application Runtime (Container Platform)
- Build Process / Observability
Build and maintain a Curated list of workload solutions that can be reused for other clients.
Thinking about the problem may be as productive, or in some cases more productive, than thinking about the solution. In many cases, the correct approach to the solution is the solution.
- Why do they need x,y,z, solutions (compliance, or other)
- discovery (IDENTIFY THE PROBLEM AND THE VALUE TRYING TO BE ACUIRED)
- Continuous delivery (CD) is the pipeline through which we need to manage a continuous flow of changes represented by work.
- we must consider what work is sent into the pipeline, how the work is initiated and how the changes are managed.
- Continuous Integration (CI) can be scene seen as the pump that fills the CD pipeline.
Continuous Integration (CI) is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.”
- Integrating changes frequently, ideally multiple times per day or even per change.
- Performing consistent validation of quality through component level testing, code scans, etc.
- Always maintaining a working build, suspending development when a build fails, and not resuming development until the issues is corrected or reverted.
Start with foundational discovery: Ask the most fundamental questions about the current state of the organization’s delivery process and the objectives of the DevOps transformation. These questions must be asked of each stakeholder, including the Business, Development, Quality Assurance (QA), Change Management and Operations.
- What are the contraints?
- Programming Languages
- open source?
If you are unaware of all possible actions you could take, you may be unable to solve the problem. by restating a problem in more formal terms, we can often uncover solutions that would have otherwise eluded us.
Make a list of the operations. State the operations. Make a list of the actions we think we can take: Make the operations generic, or parameterized.
Operation: Row the boat from one shore to the other. Operation: If the boat is empty, load an item from the shore. Operation: If the boat is not empty, unload the item to the shore.
- networking layer works
- software development lifecycle
- branching stategies
- additional folloow up questions
- diagram everything as best as possible as it exists now
- setup ideal diagram for the future of how it will be fixed (nice clean process)
- iterate on each item of the diagram upgrade
- accept contributions from the client, make sure the client is comfortable with the solution.
- be dynamic!!!
- call lenny!
Looking for a way to divide a problem is usually time well spent. Even if you are unable to find a clean division, you may learn something about the problem that helps you to solve it. When solving problems, working with a specific goal in mind is always better than random effort, whether you achieve that specific goal or not.[1:1]
Using this info, a mission statement can be formed, which will act as the North Star or guiding light for the journey. For example, a resulting mission statement may be one of the following:
We will increase the stability of our releases while increasing Developer, QA and Operations productivity and job satisfaction. This will improve our ability to retain employees, satisfy customers and be more competitive.
We will do this for our existing and new mobile and web products through the use of iterative development, continuous integration, test automation and continuous delivering applications to a production-like environment.
We, as Development, QA and Operations, will work as one toward this common objective.
We will transform incrementally, empirically establishing best practices and expertise within teams and sharing them across the organization.
The mission statement may seem like a trivial part of the process, but in reality it is absolutely vital to achieving the cross-fictional buy-in necessary for DevOps.
Product owner, scrum master… may not have all info, developers will have most of the answers to my questions.
accept your ideas being shot down, and make it super positive to ask for more input and improvements to stengthen your approach.