Mentors View: Aligning Your Team and Your Powers for Success
•Als PPTX, PDF herunterladen•
0 gefällt mir•540 views
- Getting Started on Your Journey to Success - Open Source Policy Guidelines - Policy Results in Eclipse and Jenkins - Meaningful Success Metrics
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (17)
Ähnlich wie Mentors View: Aligning Your Team and Your Powers for Success
Ähnlich wie Mentors View: Aligning Your Team and Your Powers for Success (20)
Mehr von Sonatype
Mehr von Sonatype (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Mentors View: Aligning Your Team and Your Powers for Success
- 1. Mentor’s View: Aligning your team and your powers for success Chris Carlucci Customer Success Engineer Sonatype
- 2. Agenda 2 4/28/2016 • Getting Started on Your Journey • Open Source Policy Guidelines • Policy Results in Eclipse & Jenkins • Meaningful Success Metrics
- 3. Getting started on your journey 3 4/28/2016 • Rugged DevOps, Software Supply Chain, Now What? • The Hero’s Journey • Align Your Heroes • Building Bridges • Setting Expectations
- 4. Building A Trusted Software Supply Chain 4 4/28/2016
- 5. Different Stakeholders, Different Priorities 5 4/28/2016 Where’s that release? Done! On to the next sprint. Now, where are we in that process?
- 6. 6 4/28/2016 Building A Better Bridge Between Dev, Ops & Sec • Tooling needs to adopt the practice of the practitioner • A tool is not a process and a process is not a tool; learn to leverage both
- 7. Two Philosophies • Support & guide • Objective information across the lifecycle • Each performs the task they are good at • Faster component selection and issue resolution • Bridges the developer “compliance” gap 7 4/28/2016 • Scan & scold • Reactive information late in the lifecycle • Creates rework and slows remediation • Hinders technology innovation • More expensive
- 8. 8 4/28/2016 Communicate Expectations Determine lifecycle enforcement strategy: Allows developers time to research & fix or to request waivers Everything is documented on an internal WIKI Development CI Build Promotion to staging or release
- 9. Fix the Red – Actionable? 9 4/28/2016
- 10. Fix the Red – Actionable? 10 4/28/2016
- 11. 11 4/28/2016 Building A Good Component Practice Phase 3 Reducing risk & enforcing compliance Phase 2 Creating policy & rating risk Phase 1 Understanding your environment
- 12. Interactive Policy Development 12 4/28/2016
- 13. 13 4/28/2016 What Is Policy?
- 14. 14 4/28/2016 Out-of-the-box Policies With Easy Customization Architecture Component License Security
- 15. IQ Server Policy Definition 15 4/28/2016
- 16. Tool Chain Integration – IDE & CI Server 16 4/28/2016
- 17. 17 4/28/2016 ZTTR (Zero Time to Remediation) Empower Developers From The Start1
- 18. 18 4/28/2016 Design A Frictionless Approach2
- 19. 19 4/28/2016 Create A Software Bill Of Materials3
- 20. Defining Meaningful Success Metrics 20 4/28/2016 http://www.aintitcool.com/node/44547
- 21. It’s Not Always What You Measure… 21 4/28/2016 http://ronjeffries.com/articles/016-03/you-want/
- 22. …It’s the Behavior that Results 22 4/28/2016 Manager: “Nathan, this isn’t fair. You’re just showing the number of stories, not how big they are.” Nathan: “That’s right.” Manager: “But that’s not fair!” Nathan: [silent] Manager: “All I’d have to do would be to divide up my stories into little bits and release those every month.” Nathan: [silent, smiling] Manager: “Oh.” • Soon, the manager was doing small stories, to the benefit of everyone. http://ronjeffries.com/articles/016-03/you-want/
- 23. Success Metrics 23 4/28/2016 • Short Term – Time to Value • “By the end of the workshop, we configured ~80% of our policies. Just six business days after training, we have made the test environment available in our organization” • Long Term – Quality Metrics • MTTR • WIP • New violations delivered to production
- 24. Q&A
- 25. Wrap Up 25 4/28/2016 • Manage your Software Supply Chain • Collaborate with counterparts – BA/PM/Dev/QA/Ops/Sec. • Discuss mutual interdependence and shared objectives • Automated Real-Time Feedback is a win-win • http://bit.ly/app-check
- 26. We’re here, engaged & READY TO HELP 26 Nexus Newsletter Nexus Live – Google Hangouts Cool Things in 2 Minutes Customer Success Team Training On-Site or OnlineOnline Knowledge BaseNexus Community Pages Books Online
- 28. Chicago, IL April 27, 2016 Mentor’s View: Aligning your team and your powers for success Chris Carlucci, Customer Success Engineer, Sonatype
Hinweis der Redaktion
- Introduction Name CSE - Work with organizations to build better component practices such that they can improve their software supply chain management Today, I am going to.. =================
- In general, there are 2 main requirements when deploying software and this is especially true with component management Tooling - Non-negotiable, like any other practice, developers can’t succeed unless equipped with the right tools. The major keys with tooling include: Integrate where developers work, not the other way around Needs to operate at the pace of development or it becomes a bottleneck Process - The process you put in place allows you to enable that tooling to developers (Eg education), set clear expectations (Eg What is required of me?) and at the end of the day monitor and track usage / progress So, when I walk into an organization. The first goal is understanding where we are starting from: What is the culture? Education? Tooling – What are we transitioning from? Current processes – Have developers had to adhere to prior checks within the SDLC
- Initial success metrics. What does first value mean to you? Small/quick wins BOM Remediation Enforcement Bring in the right people Subject matter experts Organizational support – change of technology, process requires top down executive support. Ability to mandate usage? Enterprise success metrics. Provide examples Education How do developers get integrated How do they get educated What can they reference for assistance Who can they contact when encountering an issue Track – At the end of the day, someone needs to provide approval – What do they need to see?
- When bringing multiple groups together, we must understand and accept that they have different priorities. Establishing this and the interactions between them is key --------------------------------------------- People How many are developers? How many are managers? How many work in operations, tool chain? Governance? OSS How many people are familiar with the concept of dependencies? What languages? Java, npm, NuGet? Tooling How many here use a repository manager? Process How many have a manual review process for component approvals? How many go straight to the internet for components? How many have application checks at release time?
- Successful tooling integrates where the developers are performing their work – IDE, CI, Repository Manager Tooling / Technology is not the sole answer – Process must be established around it to set expectations, train developers and track progress to continually make improvements
- All parties on the same playing field of information Empower developers to make better choices Initiate constructive conversations ------------------ https://www.linkedin.com/pulse/agile-transformation-what-went-wrong-pradeep-bindra Implement Agile in an Agile way. When leading organizations through the transformation from traditional software development to Agile, it is a great idea to start small. Identify only a few pilot teams that are ready to volunteer and are enthusiastic. This will not only help to focus on early, small successes in adapting Agile to the organization but it will also increase trust and help identify the barriers (organizational and personal) to fostering greater change. Starting small will help to quickly surface the delivery of business value, reduce risk, and prepare people to move the organization to greater levels of agility.
- You as the project team have the responsibility to ensure the tooling is generating valid issues Developers should remediate, not validate Lack of clarity leads to frustration, bottlenecks and lack of trust in the tooling ---------------------------- A developer’s options or path forward should be as obvious as possible What are the enforcement points? What do I HAVE to fix to be able to release to product? Ex. Fix the red violations Administration team should be easily accessible for questions ------------------ Limit the mandatory issues developers receive Too many issues results in tool antipathy A threat threshold should be defined Threat threshold should be communicated clearly
- Anyone who has ever used security or quality tooling.. Static Source Code Not every issue can be critical – Sensory overload How do you know where to start? Skepticism around the tool Cost of doing business
- This is more actionable Threat level denotes priority - Drives developer actions Advice: Fix the red Tip: Especially where expectations didn’t exist before – devs cannot immediately comply – pandora’s box – time period for grandfathering violations, cannot fix everything on day one
- This is the process that every organization goes through Discovery – Understand how my org builds and releases software. - Big need Inventory – I need to be able to identify all my applications and all the components within my applications. Do you know where they are? What they contain? Policy – Once inventory is collected, I need to identify the things that I care about Mitigation – Once you have identified the policy, you need to push this out to devs for mitigation Enforcement – This may be necessary to eliminate high risk in production application. Recommendation is to warn early and fail late, but even still, take care with this decision
- Question – What is the main purpose of a policy? Answer – To drive intended behavior no smoking? speed limit? – You are either following it or not – Yes or No don’t run with scissors password strength? Point - Policies don’t have to be these big, complicated things, they should be simple and concise rule(s) for defining guidelines around open source component consumption
- For Open Source Components, we generally see 4 main types of policy Security Legal Architecture Match State How do we decide on the exact guidelines – subject matter experts
- Policy characteristics Precise Contextual Actionable Continuous Fast
- Keep in mind Each organization is at a different starting point Different groups may sponsor the initiative, driving different directives In general, we see Most organizations begin with small goals, given the maturity of their open source supply chain Most organizations start with Auditing to better understand the scope of the problem Most organizations warn early, and fail late As always, some organizations have a compelling event as to why they purchased Eg Find struts
- Are you driving the intended behavior? Are developers making better choices? Is the software quality going up and productivity going up?
- Application Health Check is an easy no-cost way to run a report and get real results so that you can have better visibility into all of the components that make up your application. Your app does not leave your network. A one-way fingerprint is generated from the components in your app and compared against Sonatype’s Data Services to identify a Bill of Materials.
- Introduction Name CSE - Work with organizations to build better component practices such that they can improve their software supply chain management Background – Static Source Code Analysis Today, I am going to..