Pipeline Webinar

Share with

Description

Catch up on this webinar with Richard Owen (Senior Product Manager) and Oli Lane (Development Team Lead) from Gearset, as they showcase Pipelines, a new way to interact and visualise your entire Salesforce release pipeline. Pipelines provides your development team with visibility of your release pipeline, allowing you to quickly and successfully promote changes in your environment directly within Gearset.

Richard and Oli cover:

  • What’s blocking Salesforce teams
  • How Pipelines can help
  • An overview of Pipelines
  • A demo of Pipelines

Learn more:

Related video:

Transcript

Thanks very much, Liz. And, thanks very much everybody for coming along today, and welcome to the launch webinar for pipelines.

If you've been following Gear Sets development road map, you'll know that we've been working on this feature for quite a while now. So we're absolutely thrilled that it's gone into general availability today.

In a nutshell, Gearset's pipeline's functionality is a new way to view and interact with your entire release pipeline, all the way from initial development work done in your sandboxes all the way through into production.

And it gives you and your team visibility of all changes in the release pipeline, how much work there is in flight, and provides you with the tooling to get those changes promoted through your environments quickly and successfully directly from the Gaze UI. And we think it's gonna make a real difference to Salesforce teams who want to build a clearer, more automated release process that empowers everyone on their team.

So before we begin, let me introduce myself. I'm Richard Owen. I'm a senior product manager here at Gizet. And since I joined the company about a year ago, I've been working with our engineering team and our pilot users to build the functionality we'll be showing you today. And I'm joined today by Ollie Lane, who is the lead developer of the engineering team that's been developing pipelines over the last year. And he'll be jumping in the chat and on the call for any technical questions which may come up through the session.

Now there'll also be time for questions at the end. So if you have any questions throughout the webinar, just pop them in the chat, and we'll do our best to answer them through the session as well as, hold some until, until the end for the q and a.

So here's the agenda for today's session. First, we want to give you a little bit of background about some of the issues teams are facing when it comes to building on Salesforce and implementing DevOps processes. And we'll be focusing mainly on challenges which are found more in the Salesforce ecosystem than in traditional DevOps processes. I'm sure some of those are gonna be very familiar to your teams. Then we'll take a look at how pipelines will help address those issues.

After that, I'll jump into a quick overview of the functionality of pipelines with some some screenshots and views on how it works to give a bit of context for the live demo of pipelines action, which is gonna follow. And then after that, we'll jump into q and a from, any of the questions that you drop in that you drop into the chat. So with that, let's get started.

So as we see it, there are three main barriers that teams working on Salesforce face. And first, DevOps processes are primarily about organizing people in your team. And this can be quite a tricky thing to do on Salesforce platform because there's such a huge spectrum of technical backgrounds from no code and low code admins on one side all the way through to pro code developers on the other.

And there are also technical release managers and business users who have slightly different requirements and needs to add into the mix. And, overall, this technical diversity can pose a significant challenge for many Salesforce teams.

Secondly, the Salesforce platform was traditionally focused around clicks not code, and developer centric features have grown around that, but slower than in a lot of traditional software platforms.

And sales or Salesforce also comes with a number of idiosyncrasies, which need a bespoke set of tools for the job. And this can very easily lead to teams becoming siloed and release processes being less clear than they should be.

And thirdly, whilst DevOps isn't exactly a new concept, it's been around for a decade or more and even longer than that in terms of the practices themselves.

It is quite new in the Salesforce ecosystem.

And as a result, the cultural side of DevOps is still relatively unfamiliar to many Salesforce teams, and that can have an impact to efficiency of processes.

So let's just go through each of those in turn. So each so for technical diversity, a huge appeal of the Salesforce platform is that you don't need a whole bunch of professional developers to tailor your org to your business needs.

But there are some complex business problems where your best bet is still to write custom code. So that that basically creates a huge spectrum of technical backgrounds on Salesforce teams from the admins who live by clicks not code and the other end, the more traditional pro code developers. And that can lead to a separation within within teams where different folks have different approaches to creating changes.

And they have different requirements for tooling and often different levels of familiarity with the DevOps process.

And this can manifest in several different ways as you can see here. So we've got developers more comfortable with using the CLI and tools like Versus codes and working with Git on a day to day basis, especially living and breathing with that kind of version control structure.

Salesforce admins can typically be less familiar with that kind of tooling and, have a preference for GUI based functionality that push through changes, through your environments.

So from that, having a process both admins and developers can work with whilst being able to choose where they're working, we see as critical to successful coordination across the team and an efficient release process.

But this is often made a lot harder when teams are working in silos.

And getting changes from development through to production has off is often quite is often a multi well, it's definitely a multi step process for pretty much every team, but it can have a very large number of steps, going from the initial developments, creating, committing, testing your changes, running static code analysis as it goes as you're getting ready for check-in, having people review and approve the changes which you need to make, and then the process of pushing it through from one environment to another, from your development sandbox, through to integration, through to UAT, eventually going out to production.

And teams who have best practices really ingrained have have enforcement in place. They've got gatekeeping at the at the relevant steps of the process, and that helps smooth the those steps as you go from the initial changes through to production.

But in other cases, those changes are either only have documented, sometimes even lightly documented, or in the worst case, they're they're just simply in the head to the people who run the process themselves.

We can see that that's born out, really born out in the Salesforce Salesforce step up survey that we just ran earlier on this year. Over half of teams, are deploying outside of their defined release pipeline at least some or most of the time, or they don't have a release pipeline at all.

So we from this, we take we take that you need really need a process that the whole team is able to visualize and stay on top of so that your team can resolve issues quickly and efficiently when they occur.

Second challenge I'll highlight highlight is around the technological barriers and some of the quirks of the platform that teams will encounter on a daily basis. So Salesforce is a great user driven platform, but, traditionally, it hasn't been built with collaboration in mind. And it's difficult to see who's working on team on various items and features. It's quite common for developers to step on each other on on each other's toes of changes that they're making and sometimes even overwrite other people's changes.

And this can also lead this also naturally leads to, merge conflicts in a number of occasions.

And this can also be exacerbated by complex dependencies in metadata which exists, as well as some idiosyncrasies to the metadata API, which need to be overcome as well. So some key example here is here would be in editing profiles and layouts, which will often lead to merge conflicts when you're trying to merge those changes.

So this highlights the importance of having tooling, which can help members of your team as visualize where they're touching the same components as their colleagues and surface those kind of conflicts upfront so that you can resolve issues early in the process and stop them becoming a much bigger issue further down the line.

Then on top of this, with some resistance to adopting principles of DevOps culture can be a major challenge for teams.

So DevOps processes originated, as most of you know, from the from observations of the handoffs, bottlenecks, and coordination challenges which came from having Teams which are siloed. And that could very easily derail projects. So if anything went wrong during the release process, you'd end up with a complex debugging cycle and lots of back and forth between developers and release managers to address those issues.

And even though Salesforce team doesn't necessarily have ops teams anyway, A lot of teams are still structured in the same way. So dev teams are doing their changes up to the point up to the point that they're PR'd, and then release managers will take over in getting those changes eventually out to production.

So it highlights that there is still a cultural challenge which we need to overcome here. And what we're aiming to do here is to move from a state where we have different personas and roles in the team all working in their own or in their own silos on separate parts of the process, more to a point where teams are working much better together. They've got an inclusive workflow. Every team member's involved, and you've got much better better and closer communication between team members throughout the release process.

So to this point, we've talked a little about the challenges so far. How does pipelines help you resolve them?

So to achieve DevOps success, we believe teams need clarity, empowerment, and automated rather than manual processes.

And pipelines really helps promote those ways of working and removes a lot of the friction that stops teams from reaching their business goals.

The first is with clarity. It's it's really important to have a clear shared understanding across the team of what the process is for getting a change right the way through from start to finish, from conception to implementation to testing to release.

And the, the recent Google Accelerates data data dev ops report, showed that teams who have a clear change process are t so teams where team members have a clear understanding of how to get changes approved and released were eighty percent more likely to be a lead performance as measured by the Dora metrics. The metrics such as deployment frequency, success rate of deployments, the lead time to complete stories from when you started working on them, and how long it takes to recover from incidents when they do occur. So having a team wide consensus on what the state of the world is is absolutely crucial to building that process that gets out of your way and lets you focus on delivering value to the users.

And pipelines does that. It gives the whole team an overview of every change that's being worked on and exactly where it is in the release process. So at a glance, you can see the whole state of the world and exactly what steps are left to get the features you've been working on into the hands of your users.

And so for empowerment, pipelines provides empowerment for the whole team or build together. Your DevOps process is, at the end of the day, only as successful as the team members who use it, and everyone needs to be bought into that process.

And empowerment can mean very different things for different members of the team. And if you want to build an inclusive process, and we certainly believe that you should want to build an inclusive process, you need to make sure that everyone is empowered. So and that can mean different things to different people. If you're new to source control or unfamiliar with command line tools, maybe empowerment looks a bit more like a single unified UI that helps you visualize and control the entire workflow from start to finish.

On the other hand, if you've been using source control for years and you're really comfortable on the command line, empowerment means being being able to use the tools that you're already using and workflows that make sense to you to be able to push those changes through, through the pipeline.

But in every case, the really important thing is that you can work seamlessly with all of your colleagues.

So pipelines addresses the plot this by dropping in alongside your existing tech stack seamlessly. And we just so we detect changes across the different tools used by the team. So whilst developers can continue making changes in the tools they're familiar with, admins and release managers no longer need necessarily need to leave the gear set UI in order to see where those changes are in the pipeline and can participate in the exact same process seamlessly without leaving the UI.

But, we aren't going to insist on taking full control of your repo. If you're already working in your Git client to merge changes between branches, you can could use to do that.

Pipeline, pipelines supports the full spectrum of use cases so that you can choose how you want to work and do that and do that effectively.

And finally, once you've got a process that has the whole team empowered to make changes, everyone's on the same page, and everyone's pulling in the same direction, you really wanna speed that process up, tighten the feedback loops, and the key way to do that is through through automation.

So not only does automation increase your velocity, it increases the quality of your team's work by enabling those tighter feedback loops, and it leaves less room for manual error.

So pipelines is very well suited to that because it's built on top of Gearset's powerful and really well established CI job framework and uses our cutting edge deployment engine whilst also adding new functionality to streamline the release pipeline further.

It makes merge changes available for promotion to other environments and the next environment in your release pipeline showing you which downstream and upstream environments need new changes. And when you merge branches in GISAC, you'll see many fewer merge conflicts, thanks to our semantic merge algorithm, which has a much better understanding of Salesforce metadata and its structure than the standard Git merge process does. And that means it can get out of your way. It can automate all the boring stuff and lets you focus on your users and your team.

So with that, let's ax let's have a look at what we've built.

So many of you will be familiar with the CI structure of jobs in Gear Set. They've been around for quite a while now.

And the pipelines for you takes these CI jobs. So we've got CI jobs between a branch and an org and allows users to arrange them to fit their system architecture and process. So it turns that structure of the CI jobs into something where you can see the dependency chain, you can, promote changes between environments easily, and you can see the status of which changes are waiting to go into which place. So environments deployed through the continuous integration jobs, there such as integration, UAT, production, hotfix environments can be viewed as well as developer sandboxes paired with your future branches in this view, which allows us to validate and merge changes, test and deploy to environments in a really coherent and clear way across the team.

And users can set up environments and the configuration they need really, really easily. So adding an additional development environment can be done in a few seconds as we'll see in a few minutes in the demo.

We support the majority of, VCS providers. So, we've got support for GitHub and Bitbucket along with their server and enterprise versions and support for GitLab and Azure DevOps, and, support for CodeCommit will also be upcoming.

Oops. What's happening there? So here's the high level branching model we support in pipelines today and we're using for this demo. So development is done in feature branches, which are created from your master branch in your repo. And then those changes are then merged into a target environment branch. So each org has its own along with branch from protecting the state of truth for the metadata, which is being held under source control for that environment.

So you're making it you make your changes in the sandbox. You push them through to the feature branch, and then you can merge those changes, through into your staging. So in this case, it's the integration branch which is paired with the staging environment. And when we merge those changes, that kicks off a CI job to deploy those changes out to your org through webhooks. And then we propagate the PR to the next environment and move it on down the pipeline. So this provides separability of stories and the ability to promote different features at different rates.

Now this is a slight simplification of the actual model that we're using because one risk of the model is if you encounter merge conflicts, it can be easy to merge components from your target branch. So in this case, maybe from something from the integration branch back into your feature branch, which may pollute it with additional or unwanted changes, which would then potentially be merged merged further down the chain. And generally not gonna want to do that. So to address that, we use promotion branches created from the feature branch to do that merge into the target environment. So we create a promotion branch, and we'll see how that looks in the demo in a minute. And then we, do a merge from that into your target environment, and then we can promote we can create the next PR once that merges through from your clean feature branch.

So that way, any conflict resolution required is kept on this promotion branch and doesn't affect your feature branch, allowing it to remain clean for creating your Nectar VR damage.

And we also provide very clear visibility of changes to the system, so it's really easy to see what's in progress at different stages of the process to identify merge conflicts and resolve validation issues upfront. So here, we can see on one of the environments, you've got a merge conflict check which we're running and validation checks. And we can also attach Jira tickets to story so that all PRs associated with the tickets can be logged to them. And here, going out to Jira, as well, again, see in the demo in a minute, we log the data and log the links to your PRs so that you can easily see how the changes have gone through the system and jump out to VCS if you need to to be able to to inspect changes in more detail.

And stories can be promoted individually or in a group. And once they go in, they are then promoted into the next stage in the pipeline.

And team members working either in version control or in gear sets can both push changes through the pipeline. And in both cases, we'll propagate changes to the next branch in the pipeline in the same way. But in all cases, we respect the safeguards and policies that you already have in your version control. So if a user isn't allowed to promote change to a branch, they won't be able to do it through the pipelines UI either. And any approvals and review steps are also similarly respected.

Now in addition to the CI jobs and environments, developer sandboxes here on the left can be viewed directly inside the pipelines UI. So So users can set up a new feature branch. They can run a gear set call a call compare and deploy process to push changes out to it, and then they can open up a PR to the pipeline. And we can see any commits which are in that feature branch, which are gonna be pulled into that pull request. You can see them directly on the feature branch view along with the user who made them.

So there we have a commit which I've made and a tool tip which shows that I'm the user who's who's made that commit. And release managers can use that to help resolve issues and help understand which users have been making changes, which may end up conflicting with each other and may, be causing problems further down the line without needing to jump out of the pipeline's UI and go to version control.

And as changes are propagated through the environments, we also recognize where they haven't been synced with earlier parallel environments in the pipeline.

So here, as we're pushing changes through, we've got a change which has gone through into my dev one team environment, and then it's going into core into my integration environment, but it hasn't gone into the dev two environment yet. As we promote it into the SIT environment, we will propagate that to the next we'll open the PR in the next environment, but we'll also open a back propagation PR to my, to my other parallel development environment. So being able to back propagate changes across environments makes it really easy to align changes. Because as in parallel, developers will always be working from that latest and greatest code and incorporating changes made by their colleagues as those changes go through the pipeline.

I mentioned earlier about the semantic merge algorithm that we use for merging changes, which helps resolve many more conflicts than git merge can, and we'll see an example of where we have a conflict that we can resolve, but, where git does have issues in the demo in a second. But for genuine conflicts, we do flag them up. So we we can identify that we have conflicts which need to be resolved, and we provide a tool which which, will help resolve them in the UI.

So with that, let's jump out to, the live system.

So here I have a few CI jobs which are created on, obviously, on the same repo. So we've got, an environment branch underneath each of those branches representing an integration environment, a UAT environment, a master environment, which is linked to production, and some of developer environments and hotfix. So I've got a few of those environments which I have linked together into a pipeline, which consists of two integration environments for the team, the two teams, a combined integration environment, a UAC environment, and a production environment.

So adding environments to this is really super easy, because we can say add an environment from an existing CI job. So we have a few other CI jobs which we'd already created. One for the hotfix environment. I can choose that and then choose from that hotfix environment.

I can save it, and then I can link that up so I can provide that as a fast track to push those changes into production, and it will just sit there. So now any changes which I merge, into that hotfix environment, once they merge into there, they'll create that next step merge into, to push that push those changes into master and get my hotfix out to production as quickly as possible.

I can also add a development sandbox environment, which I want to then pair with a feature branch. So I've made a quick change to my opportunity object. I've added a new field on here, and I want to deploy that out first to my, from I've got that in my sandbox. I want to deploy that to a feature branch, and then I want to start pulling that down the pipeline.

So to do that, what I want to do is to add a developer sandbox.

So when that comes up, I'll give it a name. So look, rich sandbox.

I will choose my environment where I've made that change, which is this f three environment, and then I will create a new branch from my master branch to the pipeline to start the process. So I wanna call that feature op next stage, which I'll create there. And that's created it from my master branch. And then if I save that, that will appear as this slightly different type of environment here.

And then I can move that onto there.

And as you can see, there are currently no commits to that branch. It's a clean branch. I've just created that from master, so I'm good to start. I'm good to push my changes from my sandbox through into, into that branch. So we can do that directly from the pipelines UI using the standard gear set compare and deploy process.

So from here, I'm gonna choose my, just a restricted set of metadata types to to push that through. My source is the sandbox where I've made that change, and I'm gonna push that through into that feature branch. So here, I'm gonna run the compare and deploy process. And that's, so that's the gear set core workflow where we are running a compare and deploy between my sandbox as my source and my, git branch that I've just created from master here. And that'll take a few seconds to go through. So while that's going through, I'll switch back to the pipelines, pipelines view.

So if I go back to a pipeline here, then we'll see that for changes which we got through, as we were seeing in the in the slides, we do this merge conflict checking and, and we can do we can absolutely also do pre validation of those PRs, when they're raised against the branch to check that if I do merge it, will it merge successfully?

We can so if I go to one of these, one's from here. So, this one, we've done our most conflicts check successfully.

If I go into GitHub, we find that this change actually does have conflicts, and it is in a place where it normally where we quite typically find this kind of conflicts in profiles.

So it makes it, well, so the our semantic merge process makes it a lot easier to resolve those, kind of changes and those those conflicts and to be able to, to merge those changes without needing to do any manual resolution process.

So here, we've got some changes through here. We've got my, I can isolate my new fields and my, and the permissions for it which are there. I can select those. I can move on from here, and then I can run through and actually deploy those to my feature branch.

Go through to here. And from here, I can add it to I can add a Jira ticket to it. So I've got a ticket here for my for my opportunity next stage field, which I can, which I've assigned to that. And then I can add a commit message. So Next stage field from here, and then I can commit my changes to the ranch.

So as that goes through, it should only take a few seconds. And there we go. It's completed. I've got those changes back through.

And then if I now highlight my sandbox, it's got that new commit, which is there on there, and it shows that that's a commit that I just made today, with that with that same commit message.

And from there, I can now say I want to create a pull request to pull that change onto my pipeline.

So create my pull request.

So that's created that pull request there. If I close that, now we'll see that we've got an additional pull request, which is undergoing a merge conflict check right now.

And when that completes, then, we'll be able to, select it and then, deploy it down the pipeline. And there we go. That merge check has just completed, and I can now select it. Now one thing you'll you'll notice here is that, we've created we've automatically created the promotion branch in this process.

So, whereas we had that initial branch, which is the my op next stage feature branch, we've now, opened up a promotion branch, which is for that, development environment as a as a GS pipeline feature branch change. So we can now say, I want to take this branch. You can also promote multiple branches at the same time, and I can then hit promote to to run the promotion through there from here. So while that's happening, let me tell you about what what's actually happening in this step.

So we've raised the PR against this environment. This is to merge my, my feature, which is now held in my promotion branch into my developer one sandbox my developer one branch.

So as we're running that, we'll do a validation, to validate that that change, or the combination of changes that we're trying to promote here will successfully deploy against the targets. And then when that validation is complete, we do a quick deploy of that change out to the Salesforce org, and that's using the, and that's having triggered the CI job. So the change gets merged in. We'll, kick off the deployment to deploy that into the org from the branch, and then we'll propagate that to the next environment. So we'll see a new PR being opened against from my next next promotion branch against my SIT environment when that happens.

And that so, and then that will go through the process of, running its running its own merge checks against the new environment as you go through there. So we've just gone from preparing the validation to completing the validation, and then in a few seconds, that should then that should then go through.

And there we go. So that's run through. It's then, created that. So it's it started it kicked off the CI job here. It's then, promoted that change through, and we're running that validation now against that next, that next change. But it is this next environment.

So if you did that merging directly in GitHub, it would do very much the same thing. The one one difference of that is that it won't do that pre validation when you do that merge or it'll, or run or use our semantic merge algorithm to do it. But if it's a change which can be merged directly, then a developer can use that just to merge directly in there, and we will propagate the change to the SRT environment in exactly the same way.

And if I make if I get to this point and realize that I've missed something or I've missed something which caught which failed approvals or I need to make another change into that feature branch, then that change will get brought in automatically into my promotion branch. I don't need to do anything manual in this case.

And as we go through here, as that goes through, we'll also see that our, so our most conflicts have actually been rerun in this case.

I think I've clicked through it a little bit too late. But as changes as changes are made to the target environment, if there are still outstanding branches which are waiting to go into it, we will rerun that validation process and, ensure that we're giving you the up to date information about whether those changes are mergeable.

So from here, this has now gone to the next stage in the pipeline. Once that completes the validation process, we can then kick off that we can then kick off the change into that environment as well, which didn't take a second. But in the meantime, we go back to another case where we've seen here where, so you'll notice that one of these ones has come up with a with a failed validation. So I can show what what we would encounter with our, conflict resolution our first stage conflict resolution conflict resolution UI, when we, hit that kind of situation.

So here, I've got two changes which have been made by different developers, which have hit the same field. So we've identified that there is a merge conflict that we can't resolve using our semantic merge process. From here, I can say I can go to my view and resolve conflicts from here. And then in a few seconds, that will give me a side by side view of what is in my, feature branch, what's in my promotion branch ready to go through, and what's in the target branch.

So it's basically two I've created the same field twice effectively just with different parameters on there which are clashing with each other, and we can choose to accept, the changes from either side to be able to understand, right, I want to accept the changes which are in here. This then allows me to commit that merge, back to that branch with the selected resolutions. So if I do that, that'll allow me to come back to the pipeline. And then in a few seconds, it'll run that merge conflict check again, and that should come back with, saying that I've now resolved that merge conflict, and I'm then able to promote it through.

And we'll still come back to that in a second to show where we are on that.

So now we've done this validation. We've run that validation through. This change is now ready to get promoted to the next stage.

So from here, I can select it again. I can do the promotion, and then that will go through that same process of, ensuring that we're good to go, ensuring that we're good to validate, to promote it, that we won't break the environment when we do promote it. And then we'll do that same process. It'll merge through it'll kick off the CI job to deploy out of the environment, and then it'll it'll create that propagated forward change as well as a backpropagated change into my parallel sandbox, which doesn't yet have that change in there.

I'm just returning back to I don't know. I'm in those places a little bit, but going back from there, this now shows that that merge conflict that we're doing out of there, for all the a very simple merge conflict, I've now, successfully passed.

So this basically allows the process to go all the way through from your changes made in your dev sandbox all the way through all the environments through to your production and generate the back propagated PRs into your parallel environments, which don't yet have that change.

And using this, it it allows teams to move from biweekly release processes or a fixed cadence processes to being able to release stories on demand.

And technical processes really no long are no longer the bottleneck for how fast the team can move.

So the pipeline's UI makes the process of releasing those changes really simple, efficient, and very clear to visualize across the whole team. And as we see there, that change has now gone through. It's kicked off the CI job. We've generated this propagation, this new change to which targeted at the UAT branch, and we've back propagated the change, the the PR to to push that change back into the parallel environment.

And any of those promotion branches which are created, we clean them up. We clean our path after ourselves because we know you don't wanna you don't wanna end up with a thousand branch in your repo. So all of those changes will get, cleared down once the changes have been changed to be merged in successfully.

So as I mentioned right at the start, pipelines is now in general availability. It's an enterprise feature. So if you have an enterprise license, you can go and set up your first pipeline today. And if you're new to Gear Sets, you'll be able to try pipelines by starting a free thirty day trial. And, you'll see it in the CI screen. You'll have a little icon at the top to be able to switch between the standard view of CI jobs and your pipeline view.

So, go there and click there to get started.

And we've got lots and lots of resources about how to get started with pipelines. So scan the QR code to find out more about, how to set up your first pipeline, what what you need to have in place before you start using pipelines, some more details of the strategy that we support, because I know I went over it super quick just then, as well as some commonly asked questions and issues that we found as we've gone through the pilot process and that some of our users have, have brought up as you've gone through the process. And, of course, you can also reach out to us through the in app chat if you need more information.

So I hope you found this helpful and that you're excited to incorporate pipelines into the way that you develop and release on Salesforce.

And we're incredibly excited that it's gone to gone into general availability today, but we're even more eager for lots of teams to try it out and to let us know what you think about it.

And as with all the features that we release, we plan to continue to improve this functionality over the next days, weeks, and months. So if you have any feedback, we're always really glad to hear it. So get in touch with me or the team through email or through our in app chat. So thank you so much for your time today. And at this point, we'll open the floor for any questions you may have right now, and I'll switch back to the, QR code because I know I skipped through that really, really fast.

Okay.

Right. So I see the glasses had some questions which have been answered through the chat.

So let's start I'll start from the, yeah, start from the earliest other ones which you got. So when the sandbox is outdated, would the feature branch show conflicts?

Not necessarily. I mean, it it's so that first that first step that you're gonna be doing is pushing the is choosing the choosing the field that you want to push into that feature branch through a compare and deploy process. So you're gonna be making that change, gonna be pushing it into that feature branch, and that feature branch is pretty well aligned with master except for those changes which you have chosen to push into the feature branch and then create the PR from. So the chances of, showing conflicts when your branches are relatively well aligned across the pipeline, we think is reasonably we think it's pretty small.

So, yeah, does the PR target oh, we've got let's put it on there. The next one from Eric. Can someone hear? So does the PR target raise from the pipeline's UX from the dev sandbox default to the, immediately upstream environments branch to the to help prevent errors in choosing the wrong target branch for the PR?

So yeah. Well, so when when you raise a PR from here in fact, I can go back to here.

If I were to raise a PR from here, then the only option I have is to raise it to raise a PR to the environment that it is that that sandbox is connected to. So if so where where you've got your, structure of the sandbox, of of your sandboxes and where they should be feeding into, this then, it means that it minimizes the possibility of raising the sandbox to the wrong place.

And and we've got the next one from Eric. Who explains the implication in pipelines between Delta CI jobs and non Delta CI jobs and how it interacts with the PR manifest. The first part of that, I can definitely, talk to you. I'm, I may need to, hand over to Ollie for the PR manifest part. But the, so we have users who've been on the pipe on a pipelines pilot who have been using, Delta CI jobs as well as Delta CI jobs.

And so the difference main difference is that for the delta CI jobs, that will deploy to the org the changes which have the the commits which have gone in since the last successful deployment. So it's a far more targeted deployment of those commits, and it will be a and the the job will generally run a bit quicker as a result because it's got less actual work to do to merge those changes in.

One potential, drawback or caveat with it is that if you're running Delta CI, then, if you've had changes which have been made out of process into the target org, then they may they may persist even after the after the changes have gone through the pipeline's CI process. So you may want to add in an org monitoring job to be able to understand whether there are changes which are going in without, outside the pipeline's process. Whereas a non a non LTCI job is a more complete CI process where you're actually you're you're you're doing a a full compare to it of the of those message types between your, the source branch and the target org, Krishna.

For the second part of the question, Ollie, is there anything that you want to say to that, or should we get back to Eric a little bit later?

Well, we can move on for now. But, yeah, we'll we'll we'll get back to you on that that second part of the, after after the call there.

Next question that we had, so, from an anonymous attendee saying, it'll be nice after this process to be able to create scratch orgs from a scratch org definition. They commit to a test environment, then be able to package an upgrade org with the package.

So, yes, it's certainly one of the things that we should be looking at post post GA is, easier environment provision both as dev sandboxes and potentially also with scratch walks to be able to make that because we understand that for a lot of teams, it's quite hard, the process to be able to, refresh the sandboxes as often as they want to both with, representative data and and metadata.

So being able to, provision those environments more more easily and be able to refresh them from production with data that, that developers and admins need to be able to make those changes, I think, is is absolutely essential. So that's something which we're gonna be looking at, as we go post, as we go that's one of the items post GA.

Another one from Eric, saying, can we can you back propagate into a desk sandbox via pipelines?

Yes. You can. So by default, we will, open up a back propagation PR into them.

Because it isn't a CI job, I mean, to any changes which you'd want to push back into that, dev sandbox at that point would need to be manually deployed, into the environment.

Some of our users are using a combination of their phone boxes and to have longer lived branches underneath that to aid that process of back propagation. So in that case, you may have a longer lived, development sandbox branch with an additional CI job to be able to handle changes and to be able to back propagate into those and deploy those changes out automatically.

But it's, we found our pilot users working with success in, with success using that or using it, just as a as a manual propagation process.

Next question we had there from oh, we got Ollie. Ollie is answering the one from from there.

Question from Jennifer about, how are these issues for the European market with different legal regulations, privacy shield, and so on. I think that's a question which I'll need to take offline because I'm not, or maybe we can we can discuss a little bit afterwards because I'm not I'm not absolutely certain of the answer to that, but happy to address that. I'll I'll at least go into there.

Okay.

So I think that's, that is most of the questions that we had. Open for, obviously, for any other Richard, it's Liz here. Just to say that there's a couple of questions in chat as well. Okay. Cool.

Let me have a look and make that a little bit bigger.

Oh, where are we?

Okay. So we had the question of, so we had the question of what what what is a Delta CI job, there, which I touched on briefly. So that is, that's a setting on a CI job, which allows the deployment to be done just using the commits from the latest successful deployment to present. So isolating, it's a much more targeted much more targeted to deploy, which generally run quicker, but, users may need to take a bit more care about ensuring that they have they know exactly what is in the target org in that case, in case any changes have been made out outside of that outside of the standard process.

Cool. And then, we got one from Brian Schumer saying, we're currently not allowed to collect connect GATEC with Git, which keeps us from being able to use pipelines.

So, yes, at the at the moment, the, so we need to be able to connect to, one of the supported Git, or one of the supported VCS providers, to be able to use, the features and that we need in pipelines.

And the I think this might be a good good case for us to, touch base offline and discuss and set up a call to discuss the requirements that you have and how we can use our process to help to help you. Because we have a we have custom Git connections that we can use for standard CI processes, but they're not, the some of the more advanced features that we have from the native VCS connections, we use in pipelines quite heavily.

So I think it it would certainly be worth setting up a call to discuss that.

So next question that we have, so from so one from Joseph Waldy saying, so where does the peer code review fits into this process? So at this point, so I mentioned a little bit earlier on that our, that we respect the, approvals and review processes, which are in VCS itself at this point. So, if you need to have reviews completed, before you're able to promote to an environment, then we won't let that promotion happen before those reviews, before those approval steps have been completed.

In the short to medium term, we're planning on exposing more of that information inside the pipeline's UI as well, to to help aid, that process of, making it as seamless as possible and decide to allow you to do much more stuff from within the pipeline's UI itself.

But we certainly won't be letting you, do those mergers inside the Pipelines UI if it's something which you're not actually allowed to merge at this point.

Would we be able to drop a get that pipeline into the gear set pipeline or the other way around?

So really depends on the on the processes which which which we're talking about here and what we're what we're looking to do, because the CI jobs themselves have outbound you can define outbound webhooks, which can then trigger other processes. So you can have some integration on that direction, and that's something which we're also looking to enhance as we go further down the line.

It really depends on which steps you're looking to do in the like, give that pipeline as opposed to the gear set pipeline.

The and how how it kind of fits into you the the structure of what you're doing of what you're doing today. But certainly, we'll be very happy to, explore that further.

And I think that's Sorry, Richard. I've just got, one more question to add in there. I think we had a question on, can a development sandbox be tied to multiple feature branches? I suppose my dev sandbox is working on three concurrent stories. Yes. So you can do that. So if I go to my pipeline here, I can say I wanna go to my my developer sandbox thing here.

And so this this is a good use case for, if you got shared sandbox, for instance, but you're working on distinct features. So you can say, I want to go to I want to use my same sandbox, and then I want to create a new branch. So feature.

Cool.

Cool feature. Clear that branch, and then I can connect that in exactly the same way. So if I add that through here, I can add that through there. And then you you can do that same compare deploy to push the fields that you want to or to push the the code that you want to into the specified feature branch, which can then get pulled onto the pipeline in exactly the same way. So that's it's certainly the way that we designed it to work, and it's a way that it should work well.

Okay.

I don't I'm not seeing any other questions coming through here now.

But I, yeah, if there is anything else which comes up as a result of this or from, if you're back at the, the recording when it's shared, please do, bring them up. I'm more than happy to, set up calls and discuss any any questions or issues that you have. The for anybody on the enterprise tier, the, the pipelines, icon will be is available there. It's open as in there in the CI screen, so you'll be able to start getting up and running and, start working with pipelines and seeing how it fits into your process.

With that, just like to say thank you very much for for coming along today, and have a great rest of the day.