Transform your developer experience with Atlassian Compass

hello and welcome to today's webinar on transform developer experience with compass uh today we're going to talk a little bit about the crisis of modern development why we actually need to talk about transforming the developer experience what devops is all about and what the development workflow looks like in an ideal environment and then we jump right into the atasan compass demo we will end with a Q&A session where you can ask questions this webinar will be recorded and you will find it on our website later on my name is Yan chansky I'm the head of product and partner marketing here at EIC code and I'm joined today by Marco clti our CTO thank you very much Marco that you are with me today so just to introduce effic code briefly EIC code is uh an international consultancy company building the future of software currently we are 300 million euros of Revenue working with 650 professionals across 10 different countries and the last 12 months we've been serving 1,600 customers across very different Industries the key industries that we usually work with across like atlassian products and and all of the devops tooling and devops consultancy are finance and in Insurance the industrial embedded environments transport Transportation like automotive and the then technology media and Telecom organizations we're based in Continental Europe Scandinavia UK and us which are of course for us the the biggest areas that we work but then we also serve customers outside these regions with the people we we work with in these areas yeah when we talk about transforming the development experience something might not be right so let's let's talk about that imagine developer wants to deploy a single feature but has to juggle with at least 15 different tools instead of focusing on coding they lose hours and meetings debugging pipelines and painstaking navigating through buggy yo files and searching for documentations in very different tools like Confluence SL email jur tickets mob boards and this phenomenon known as tool sprawl Forces teams to manage up to 90 different tools greatly increasing complexity and cognitive load so Harvard calls this the business trap um custom developers feel productive while fixing pipelines but is that having a real impact what what do you see about this topic Mar yeah it's so we've had devops now soon uh soon soon approaching 20 years uh somewhere between 60 70 years from coining the name and of course from from from the past devops has existed as well and what we've seen happening across the industries is that there are literally thousands of different tools that can be used to improve the developer pace and help them in their daily work and across the years of course organizations have implemented these tools into use in different teams in different parts of the organization and it has led into the maintenance burden so many of the researches now show that most teams use even more than half of the time just maintaining the tooling instead of actually focusing on the core business or the actual development of features for the users right and also the people behind the code also suffer right two and five it professionals it said that um are a high risk of burnout and more than 40% of those affected are considering leaving the organization in the next six months so buron is not just a marginal issue it's a um costing organizations around the globe billions of dollars every year and this crisis needs a solution I would say so devops was revolutionary until until it wasn't by solving collaboration it created a new problem complexity teams now need experience with kubernetes terraform Argo just to ship hell w essentially Dev Hope's teams are now driving in tool creation and with it came this ticket patory who to ask when I need something whether it's a new pipeline a security tool or or repository um where's the right documentation uh imagine you're a developer in your company today and you need to start coding um and as a trend reacting to this kind of adaption now we see that as development decentralizes tool chains centralizes what do you think about this moves yeah it's uh the move has been quite clear roughly the same period as as DeVos have has existed so of course agile methods aim at serving the customers and the users of the products that are being created and where have we have been moving from functional teams towards uh stream align teams or teams that actually serve the customers and are like are able to have these cross skills and have various skills within the within the team to actually uh deliver functions across the whole software ecosystem organizations have and what this has led to of course then that the developers of the org organization or development teams are not only focused on the small piece of of functions or functionalities that they've been working previously they have to know not only the software ecosystem but also the tooling ecosystem so the development is heavily decentralizing moving towards the kind of devops you build it you run it way of thinking while yet at the same time we know that there are dozens some organizations have hundreds of tools to Aid the developers we realize that in the it organizations and the shadow it where kind of these development teams are working on their tools themselves it needs centralization and for example platform engineering developer experience both are aiming towards the actual centralization of these tool chains and managing both the maintenance burden but also as said the information burden so that these these C centralized teams cross functional teams they wouldn't have to be able to understand everything across the whole product and the tooling but have kind of understandable information without having all of that background knowledge so that's also part of the different phases I would say about the the cloud adoption right so you start somewhere and you mentioned that in one of um our customer conversations with d TRS that when you start typically at a customer it's like scattered across you have a lot of Shadows it um development teams have their own Taste of tool combinations and then you have the platform teams that try to consolidate everything a little bit then you have the second of the cloud adaption where you move towards decentralization absolutely and also looking at how many if you take only just Version Control Systems you have big buckets you have gitlabs you have gith hubs across the organization the bigger the organization the more instances you'll have this uh centralization doesn't only have selecting between a Version Control System it's actually consolidating the similar Version Control Systems together and there are lots of other tools like test automation or delivery tools and Cloud environments that also need centralization so this is a big movement while at the same time we're of course in the world of AI where you have to learn new skills and new tooling on top of everything that you're already using so I think when we talk about internal developer platforms and you already mentioned that uh and how to transform developer experience and what the value is for me it really starts with devops itself so you mentioned that and I heard in one of the uh preparation YouTube videos before uh someone called them the the Unicorn Engineers the combination of of a developer and an operator and this kind of full stack role I personally I think it was never really the idea and the definition of it I always thought of De Ops of this you have de and you have Ops and it's really about the interface and the relationship between them what you think about this what what is yeah exactly like that so of course like we see devops moving towards like the the future future fut istic approaches such as uh platform engineering which is heavily taken from the fact that when you have developers and you have the operations team within your organization like them working together is very important part of the equation but also you have to have some level of of tooling so that you're not increasing the cognitive load and then of course the people who have passion over devops they might not have similar passion over developing new features and it leads into developing new processes where of course the experts on devops and the development are important but also you have to kind of start building the kind of the platform services and you have to lean towards the tooling that provides automation into the different phases of software development so we take a look at some of the some of the concepts behind devops before working toward for its Compass let's take a six common very common steps of devops these can be quite familiar to to many of you but I'll still go through so when you start working on a feature you usually have a requirment management system or you've already made a decision of the things that you're going to be developing next and for this purpose of course we're using jira and now if I look at regular developers life they're working on a product I'm working here with a product called week number it's a website showing the week number and I have myself uh ticket change colors to Blue now when I look at the code here so I'll just give you a sneak peek of the code so this is one version of the code on my local computer and as a developer of course I want the cognitive load to go down I want to find a way how to do it in such a way that I can just code and deliver the feature what I would do change colors to Blue I would essentially go to the terminal I would make a new Branch it was week [Music] number-3 colors to Blue like so I have a new Branch I haven't actually made any changes but I'm going to push it which means that it's going to create a branch uh with the the J ID and colors to Blue and it changes automatically from selected from for development into in progress which essentially for me and the developers regular developers the way how you want the underlying automation to work you want to have your flow it's comfortable where you're comfortable already and all of the information is collected in the background then for like organizational strategy and steering a management purpose also to be able to understand what's happening in your project and in which phase then of course the next Pace next step of of devops one of the key practices of devops is continuous integration continuous deployment and continuous delivery essentially the automation so now I've moved the ticket from change colors to Blue but I also want to have automation which verifies that what I've done is actually working as we expect it to be working and that the features that already existed are still working as they used to work also all of the automation regarding then whatever processes you add in afterwards in in the in the process are being run and here you can see I have my pipelines defined in bit buckets so I have the build in progress what it does it installs me the packages it runs lint checking the uh checking the code quality and also it runs a set of tests so a process of continuous integration automated process which does in this case test and Link and deploy to production essentially something that's completely automated once again me as a developer I don't have to start setting up any cicd tools I'm getting it from say a project template I'm starting to use it and I have it already there then the next step would be of course continuous quality assurance this is something that usually is called test automation but now especially when we're using tools such as uh jira and big buckets you can actually take it further than just test automation you can link the test cases into the requirements that you have and you can make sure that whatever you do is tag it in such a way that the requirements are linked into test cases and in this this case I'll show you a set of tests which are run as part of my CCD or if I wanted to run them locally I would run currently a four test cases for get week number and this is the way the quality assurance is done today whether it's with AI Assistance or without AI assistance everybody in the development team and stakeholders should be able to read and understand what the test automation is actually doing so one of my favorites which actually AI helped me do is should return coret week for a leap year so when I'm developing an application that shows the week number I would have never myself came come up with a with a leap here test or a week number and now if you write it in this format no matter how the test is actually formatted here correct week for leap year coincidentally you're probably also able to understand this case so I have the leap year date from 2020 and I'm testing that it's still week number nine so I have the test automation here but the actual gist is to have the test automation connected somehow into the require then of course the fourth step which is quite natural after all of the the development and continuous uh delivery using test automation is how do you deploy your application one of the key parts of for example platform engineering is of course kops something where you define also your infrastructure as code and it enables you to actually build build your applications in such a way that you also have kind of the infrastructure well defined and automated and this is also one of the the modern devops core things to do so whether it's terraform and AWS or or some other way of doing it it's also natural part of how you Del develop software and it's also just to interrupt um go ahead good point where it typically see where we see an explosion of tools right so this is the the wall where developer runs against so we have all this kind of AWS gcp platforms we have you mentioned kubernetes and Argo and wrench and all these kind of tools and platforms um so here it gets really really complex um when it comes to the tool setup and how we actually bring software to life y that's correct and that's also one of the parts that in the traditional devops teams usually have taken care of themselves whether there's a devops team or a development team it's getting saturated uh but this is one of the areas which really increases the cognitive load on the teams you're developing on a feature that's maybe changing your user interface somehow yet at the same time you have to know how to provision Amazon S3 buckets or how to make migrations on the database is that you defined how to take care of SSL certificates or networking between kubernetes nodes or whatever kind of this is the knowledge that then devops Engineers would love to do but are not necessarily the right place to be working then for the regular developers so I've actually made the the change and it's running the build and I'm ready to make a pull request so I'm creating a pull request from colors to Blue see it update colors to Blue create pull requests and now I'm ready to hand out my feature to my development team or whoever is doing the approval on the code so of course this is for you to see pretty simple functionality uh but this is kind of conceptually how the teams are working and now I'm still working in my comfort zone my my code the ter then did the place where I handle all of the reviews but then on the view of the pro project itself you'll see that my ticket has moved to in review so the whole organization can see that I'm progressing with my task it's currently in R then let's see we probably have a deployment yes just now done a production deployment which means that I can also so of course of course at this point you would probably build a staging uh some sort of a staging deployment or production deployment but since I'm a onean team for the demo I'll just have it done so that I merged it uh running the deployment and now it's merged into main my new Blue version and if I go to my favor demo site week. hopefully. works and I open it it's blue with the six which is the iso European way of looking at weak numbers like so and naturally in jir it would be done so this is essentially a very simplified workflow with lots of automation lots of kind of uh lots of processes and practices put in place that just came out of the box by me just starting to work on these tools and then you mentioned um that with the deployment phase and when we go into cloud and we use all these kind of tools and uh AWS and the account management and is it save or is it not we have and also the cost section don't tackle that here but um security tooling obviously comes in place and also compliance tooling various different platforms out there that help you um in the flow to get the right information is it safe is your code um is your code safe are the npm packages that you're using is there avability and so that helps you along and um also AI is a huge part of that uh as well now one of the key things you just mentioned is we uh at e code as I said we work Lots with regulated uh organizations uh embedded organizations and those organizations usually have some sort of a bill of material that they have to collect on everything that they Seck on the manufactured Parts but then there's also software bill of materials and you mentioned npm packages and so coincidentally I'm using npm here but whether like no matter what the the development environment or coding language is it's driven by open source which means that you we're using lots of thirdparty libraries open source libraries and those are very focal very key part of our application it's not necessarily visible for the developers but when you're starting to deliver that application you have to really know the so-called software bill of materials so the sbone and this is one important part of the Securities by starting to even know what you have in place and then adding all the tooling that goes into looking at kind of your code quality and uh looking at potential security problems like code ql from the github's advanced security is is one tool that can show you around on on security issues you might have in your product and then kind of a combination of those one of the key parts of functioning devops and devops practices is that today my build might look green on the security but the same product with the same esbon the same depend encies might be vulnerable to borrow because an issue has been found in one of the libraries that I'm using and it's super important when we build these kind of devop De devops automation devops practices that we can also continuously do it on the existing software and this is where we really increase the cognitive load this is where we really increase the load on developers unless we build automation and and healthy devops practices and so yeah the last point because it doesn't stop there right so uh sometimes we have passwords so we need a vault management and when it runs well hopefully it runs but sometimes uh Murphy's Law to to:' in the night something happens so we have service Management in place as well and all the Monitoring Solutions um so this is also something uh which is something sometimes a black box for developers and they don't want to care about those things but it's also there and we need to all this kind of information that comes together and the real big question is where is this where it comes together yeah yeah absolutely and and now when you look at it from kind of the developer team's point of view so if you look at these six that we've we marked there and you have the Automation in place you have your happy flow through through through the feed is the same way as I just showed you would be going with the kind of devops Mantra you build it you run it you have your decentralized responsibility you know you have a feature team you can actually build features for your users instead of working on a single functionality somewhere along along your um architecture an