SKILupDay

Anything available already in org, Value, flow, and Cost

money ...

Budget always takes the priority unfortunately before considering what matters !!

Talk to people who have already done it - all organizations need to share more about their toolchain architectures

It is important to define a set of standards for each case

Purpose which it fulfills towards the incremental features you need, keep the flexibility intact , no vendor lockin :-)

Architect it so that you can use a value stream management tool to tie it all together and get end-to-end cycle time data and insights into your constraints

Experience defines means, budget defines tools

This is a great question. Important to know your goals and pick a combination of tools that best suit your specific situation. Everyone has budget constraints. Need to be careful to pick a toolchain you can afford not just a tool.

I choose tools basis upon organization #culture #people #process #technology.
Maturity of your #ContinousIntegration

List is endless.

Pipeline started working at night and custome visit was on next day ... still not aware what was the issue and how it worked

answer is easy introducing it . Only the timeline & teams were different :) #devops

best its introduces value traceability and a choice to release on demand based on insights

Best that it breaks often, and worst that it breaks often. Perspective, perspective! :)

@alalit complete agree its awesome in all the cases

My best experience with CD pipeline: large telco system manufacturer reduced time to delivery from 18 month waterfall releases to daily DevOps release candidates. Worse: A large insurance enterprise implemented CD w/o enough testing. Quality problems caused project cancellation

@alalit that's awesome! Love it

Devs use pipeline as personal playground and regularly change gates without informing anyone. Sec: Why haven't you run security checks in 3 weeks? Dev: It took to long, now we only do security checks when we know its not a problem

gazillions I guess :)

(edited)

100+ i know and still counting

always one more.

Toollist ++

my guess is 120. :)

@alalit Totally!

I am counting at the moment. Will let you know once we reach towards the end of the year 2020 :D #Devops

infinite... because they all keep changing and people build their own. But typical pipelines seem to have between 10 to 20 distinct tools

Is it like counting a jar of beans?

Do we really need to know? It should be requirement specific rather than choosing from the bucket and not knowing which tools align with your requirements and then losing $$$ from your investment.s

@mhexcalibur People need to share their reference architectures so that the community can learn from each other

Sometimes yes to understand what we need make inhouse reuse and buy

It is not important

@felidue I second, tools are build for purpose and the purpose is focal to the practice

@BealHelen lol

Slowly, slowly, catchy monkey!

Explain your Whys and articulate it, ensure business interest also aligned and run a quick experiment

Start with a Value stream mapping exercise. Assess, analyze and then start small.

CI/CD is a change agent, introduce it like a change initiative

Start with some stakeholder mapping, then some value stream mapping, then get some experiments done and make local discoveries global improvements!

Phases ... many many phases...

one value stream at a time.

@BealHelen Yes, and this is the most challenging aspect of DevOps in my experience.

I use seven step DevOps Engineering transformation process that focussed on building a model application and using it to build out. The 7 steps are Leader Alignment, Team Alignment, Discovery, Assessment/Roadmap, Implement/Realize, Operationalize, Expansion.

CD roots exist in Agile Principle i found two principle close to it. i will say its one particular engineering practice

Not really, I think it has evolved more than any other practise under the DevOps movement. It has brought in the most technological aspects of DevOps practices.

CD is the 1st of the 12 agile values - in this respect it's about process. In my mind, the world of DevOps has commandeered it in the context of the CD pipeline or DevOps toolchain

CD is miss-understood. I see "CD" meaning is ambiguous. Continuous Delivery, Continuous Deployment and Continuous Delivery Pipelines often are referred to as "CD" even though they are related bu different.

Or maybe CD is not an extension from Agile? Maybe a reaction as well same with what we heard from DOES20.

DevOps is not a market, but a tool-centric philosophy that supports a Continuous Delivery value chain.

@davefarley77 once said to me it shouldn't be called DevOps, it should be called CD and I'm inclined to agree, but I think it's too late; it's already too tightly associated with automation

totally