Software and mobile application development are a quickly changing specialty now, and lately, Continuous Integration or CI is considered the best practice in automating the test suit. All sorts of integration and unit tests run on every merge to automatically pull the requests with continuous integration. You may also know it beforehand itself if there are any problems to occur during the merge. You may use a useful CI tool with an appropriate Version Control System, and it is also a best practice to have a review through a pull request and enforcing to pass all the tests before the pull requests getting merged. These early fixes can save a lot of money for your enterprise and keep your teams happier and productive.
The function in CI in the real scenario
Continuous Integration can be effectively administered with the help of a CI tool that can communicate effectively with your VCS. You can set up the CI tool of your choice in the repository and custom set the rules while your test suites run. Once the CI tool is set up, and all rules are there in place when you take any action to trigger a test, the CI tool will run a script in the background, which will configure your environment and deploy changes by running the test suite.
On completion of the test process, the CI tool can also provide a log with details as to whether the tests are passed or when and how the builds failed. You may also set up the tool so that the changes will not get merged until passing the test. By this approach, you can ensure that you are not making any new bugs live into your code when any of your team members propose and initiates a change.
Another best practice is to perform the test in a standard testing environment like an SF scratch org or sandbox. While using the automation mode, it is also preferable to create some disposable environment like scratch org to test the changes instead of introducing those into shared org. In this way, the Salesforce CLI will automate the scratch org creation as a part of your overall CI process. Another cool aspect of using a CI tool is that the use of Salesforce CLI will let you script all such tasks in full in the continuous integration configuration file irrespective of whether you are using a package-based or org-based development.
Setting up
For those who have not tried CI before, there is an official trailhead module by Salesforce, which will explain the process of constant incorporation using Salesforce DX with a set of examples or repositories of the most popular CI tools. Most of the leading CI vendors put forth two repositories:
- One is based on the given model of package development for the teams which use unlocked packages or scratch orgs for change deployment.
- Another one is based on the model of org development, which is for the teams using Metadata API commands and sandboxes to deploy changes to production.
Each of these repositories features a readme that can walk you through various steps in setting up the CI vendor’s tool in SF DevOps projects in given VCS. It may also include simpler CI configuration files with authentication details of the users. Some of such standard vendors with supported repositories are as below:
We may choose such CI tools based on requirements. Primarily, choosing the right vendor depends mainly on the needs of your teams. You may also use the CI tools forthe Lightning Platform. While selecting an appropriate CI tool, here are some inputs to consider.
Consider how you want to run your test
Some may prefer to run the tests in your servers, whereas some others may prefer to run it on the cloud. Your enterprise needs to have on-premise solutions if they want to gain access to any private network resources. Alternatively, you may try to get a CI vendor that supports VPN. Also, check if your organization has the technology resources and skillsets to manage and run CI servers. If this is not the case, then you may opt for an excellent cloud-hosted solution.
The version control system tool used
Another consideration to make while choosing an appropriate CI tool is what kind of a VCS tool you use. Most of the VCS tools do have integrated CI tools too. For example, if you are using the VCS like GitLab or Bitbucket, they come with an integrated CI tool. This will make set up much easier and quicker. Along with the built-in CI tool, both these version control systems can also work with the other modern CI tools.
The OS which you test on
The third consideration is what operating system you prefer to test your changes on. SF DevOps CLI can support Windows, Mac OS, Linux, and Ubuntu. The development team should think of the scripts and commands they are familiar with to execute it.
Pricing of CI tools
This is one primary concern of enterprises and surely a consideration while choosing a CI tool. The pricing of such tools may vary from vendor to vendor. For example, Bitbucket may charge youfor the total duration (in terms of minutes) used, which could be much cheaper if you are running only very few tests per each build. There are free solutions, too, as CircleCI, which may be a good option for the beginners in CI.
So, the ideal approach is to consider how many tests you run per each build, and often you must access it. This plan can be checked against the available options and compare the prices. Along with all these, you may also consider the public vs. private VCS repositories. As discussed, some vendors may offer your hosting with CI resources for your open source projects.
When it comes to Continuous Integration tools, each vendor may be unique in what they offer and what they charge overtime. So, it is advisable to do thorough research in light of your CI needs to identify the most suitable system which works the best for your team.
