First of all, what is CI/CD?
In a few words CI/CD workflow, or Continuous integration & Continuous delivery is about automating as much of your development and release processes as possible. Reviewing each part separately, Continuous integration (or “CI”) means automatically moving through a release pipeline for combining and testing packages, before pushing them to production. Your package items are brought together, and then tested and validated to avoid any issues that might arise on release. In such case, automated testing and validation reduce the time it takes for the team to review new work and makes sure that everything will be deployed successfully at any stage in the process. Continuous delivery, being an actual goal of CI/CD is a way of releasing new functionality to your end-users as soon as possible after the successful completion of the development process. Such workflow becomes more agile and flexible in delivering each part of work quickly, continually, and less risky thanks to easier testing.
So, if you are one of those teams turning to CI/CD to automate your workflow and quickly deliver quality work to your end-users – Zuppio should definitely come in handy here. Along with being a mass package upgrades tool, with our latest release, Zuppio can be used in your CI/CD pipeline – and in this article, we will briefly describe how to deal with this new functionality.
Zuppio’s CI/CD feature: step by step
In Zuppio you can connect your GitHub or Bitbucket and enable webhooks – so basically use our tool for a continuous delivery process.
If a text format is more comfortable for you to perceive information – you are on the right page – right below we’ve described everything in detail with screenshots so that this article can serve you as a kind of handy instruction. If you are more comfortable with the video guide or just curious – at this link you can check out our recently published video with step-by-step CI/CD instructions.
So, the first thing to start with – is moving to Zuppio settings to enable CI/CD feature and adding some details. Right here you will need to authorize your organizations if you haven’t already, and add a Git connection for further work.
This step is not so complicated, but here’s the important moment when you connect your GitHub or Bitbucket using Personal Access Token (PAT). In this article we will describe the process of connecting GitHub to Zuppio, however, the Bitbucket connection process won’t require any additional knowledge being absolutely similar.
To get the token just go to your GitHub -> Settings -> Developer Settings -> Personal access token and click Generate New token here.
Put a checkbox near the Repo section, add some notes for future understanding and continue by clicking Generate token button at the bottom.
And here we go – just copy the recently generated token and paste it into the PAT field.
After we connected our GitHub to Zuppio – let’s move on and start the work process itself. Some of the next steps should be familiar to you if you have ever used Zuppio before. However, if you need a quick reminder about jobs & steps in Zuppio functionality – feel free to return to our Zuppio Guide.
Let’s add a new CI/CD job with target organizations as usual and start with CI/CD step in it. As you can see in the image below, all other component updates are unavailable without Source organization added (but anyway it’s enough, for now, to show you how CI/CD works without creating any complex workflows).
After naming the step and choosing CI/CD from the list, we move to the Components tab: here we choose our Git connection, which was added recently, and choose the Repo.
As you can see here – Zuppio can work with both SFDX and Mdapi project formats, let’s choose the SFDX branch for this example and specify the path to the folder with the content we wanna deploy (Apex classes).
In the screenshot below you can notice that we don’t have any Apex classes yet in our Target organizations, that’s why we choose exactly this case to easily show you changes after.
In the Repo, we go to the actual classes which we will deploy – copy the path to the folder and paste it into the field. One more thing left here in step settings is webhooks – enabling webhooks will make the step being executed on every code change in our Repo, and this is exactly the part which makes our job continuous. So, we enable webhooks, check if everything is correct, choose on-error actions and click Save.
To show you the result of all our previous actions and settings – let’s make some minor changes to the Repo, commit and check our job. As you can see – the job has started to run without any input from our side thanks to enabled webhooks. After the successful completion of the job on every org – let’s make sure that our Apex classes actually got deployed – you can check they appeared on every Target org on the screenshot below.
And that’s how our new CI/CD feature works – please feel free to reach out to our team with any additional questions, more complex workflow examples and interesting cases.
