Relate a DevOps with Changes - how ?

[JK1]

Hello guys,

it was really nice on the SNUG BG event and i hope we can make this group as good as possible. Seems I am the first to ask something

As it is fancy to use DevOps and agile methodologies today, of course in our company we use it as well. But I have a struggle to align the DevOps way of work with ITSM, especially with changes. For example, a new code is created and have to be deployed on few environments and platforms, and several config actions required and 10 micro services are to be deployed - per environment. And we will need a single change per single one of these activities, so we end up with 50 or more changes. Of course we cant ask the developers or DevOps team to do that as this will take more time than the actual work (not to mention they see it as a single action that needs to be tracked - Bamboo does it that way ). So we ended up with master (or parent) change which spawns as many as needed child changes -   so the developers will have to open only one change, and select from there what is needed.

But I want to ask for your experience on this hot topic. Have anyone done such thing, between changes and devops ? And if yes, how did you do it ? Any experience and ideas are very much welcome!

Thanks in advance!

Joro

[mitzaka]

Hey Joro, congrats on being first to ask a question here in the BG SNUG:))) and I am glad you liked the event, I also think it was great:)

On the DevOps <> Change Management question, I can share how we tie the two together in our team. Our dev teams use Stories to track the tasked work, which we related to change records (we have the ability to spawn a change from a story) if needed.

This very much depends on your use case (how often you push new stuff - for example Amazon push new releases every 11.7 seconds, yep amazing https://techbeacon.com/devops-odds-change-management ...:))

So if your deltas are not affecting big chunks of environment and you don't need to have approval process for them, etc., you can use a master change record, and then change tasks which are auto-related. They are OOTB and are simpler in workflow , but still give you the parent-child track. Just some ideas.

Cheers and I hope you find your tactics, share if it's working later on. Looking forward to speaking to you soon again.

Dimitar

[Miro]

Hi Joro,

This question is very fundamental and at the same time quite broad. We are currently working with several companies in investigating and analyzing their continuous integration and deployment processes.

We need to discuss further how the request for change in SNOW can be related to the committed code change in Bamboo so that the DevOps team or developers do not need to manually track their progress/change closure in your specific context. The general approach would be to have a master change with many children/related changes.

Let's discuss it further because this question involves a lot of stakeholders, and relates to DevOps tool chains, processes and practices.

Let's follow it up together.

Miro

[mitzaka]

sulphy - good stuff, please keep us also in the loop. It will be interesting what you will come up with.

[JK1]

I fully agree, but it seems to me much more suitable we align the Jira and SN tickets ( Jira to SDLC tkt ) as Jira is much closer to Bamboo and BitBucket ( and whatever they got - Atlassian ), so its going to be easier that way and more precise. But lets see you know the resistance we get on every change we try to do

Cheers,

Joro