Source Control and Continuous Integration

So far, we have been making changes in a scratch org for the FormulaForce application. This has worked well enough, as you're the sole developer in this case. However, when you add more developers and teams, other considerations come into play—mainly, the traceability of code changes and the monitoring of code quality as multiple streams of changes are merged together.

This chapter also sees packaging take on more of a prominent role. As discussed in Chapter 1, Building and Publishing Your Application, there is a need to create a beta or release package for your own internal testing and, of course, for the eventual release to your customers. Careful management of your release process is important to you and your customers if they want you to demonstrate compliance and auditability with respect to controls for your...

Development workflow and infrastructure

A development workflow describes the day-to-day activities of a developer in order to obtain the latest build, make changes, and submit them back to a repository that maintains the current overall state of the source code. Having a solid, well-defined developer workflow, supporting tools, and infrastructure is critical to the efficiency of any development team.

The first thing a developer will want to know is where the source code is; basically, a source control system, such as Git. The next will be how to get it into a form that they can start executing, and then, of course, make changes to implement whatever feature they are working on.

Throughout this book, we have been using the Salesforce DX CLI; however, in this chapter, we will compose a number of commands together to automate some aspects you have been performing manually, such...

Developing with source control

Now that we understand the general developer flow a bit more, let's take a deeper dive into using some of the tools and approaches that you can use to share changes in source control. In this case, we will be using some specific tools to populate and manage the content of our chosen source control repository—Git. To provide an easy means to explore the benefits of a more distributed solution, we will use GitHub as a hosted instance of Git (others are available, including broader developer flow features). The following is a list of the tools that we will be using in this chapter:

• GitHub: Ensure that you have a GitHub account. Public accounts are free, but you can also use a private account for the purposes of this chapter. Download the excellent GitHub GUI for either: https://desktop.github.com/. This chapter will use the Mac edition...

Hooking up continuous integration

So far, we have been depending on the developer to ensure that the changes they push to the GitHub remote repository do not cause regressions elsewhere in the application. However, this is not always a fully reliable means of determining the quality of the code, as the main code base will likely have moved on due to other developers also pushing their changes. When integrated together, they might cause tests or even code to fail to compile.

Continuous integration monitors changes to the source control repository and automatically starts its own build on the fully integrated source code base. Failures are reported back to the developers who last pushed code to the repository.

In this part of the chapter, we are going to explore this process using the popular Jenkins Continuous Integration server, which uses a script that is also stored in source...

Releasing from source control

Throughout this book, we have been creating packages using the Salesforce DX CLI manually. When you are starting out with a new package, creating packages is arguably a less frequent operation, and you can certainly continue to issue these commands manually, using the preceding pipeline to simply confirm that your code base is stable enough to create a test package (I would recommend you use Git tags for each package version). However, once your number of releases and their frequency grows, you may want to start to add some more automation.

It is possible to automate the Salesforce DX CLI commands related to packaging through the Jenkinsfile. To consider this, though, you must first think about your use of branches within source control and, from that, determine what changes in source control warrant a new package version to be created, and,...

Automated regression testing

While Apex and Lightning Web Components tests are very much key tools for monitoring regressions in your application, the limitations and scope of the functionality such tests can cover is small by design, since they are unit tests, not integration tests. Thus, they are not particularly suited to performing large data volume or full end-to-end user interface testing.

The preceding pipeline configuration creates only one scratch org with a given configuration. You can, of course, create scratch orgs of different types to perform different kinds of testing. At the time of writing, the Scratch Org Template feature is in Pilot. This allows you to customize your scratch orgs to pre-install other packages, test configurations, and data. This is ideal for creating a suite of test org templates, for example.

Here are some considerations for implementing...

Summary

In this chapter, we have seen how to scale developer resources for the development of your enterprise application using industry-strength source control tools, development processes, and servers such as Jenkins.

Some of the steps described in this chapter might initially seem excessive and overly complex compared to developing in a more manual way. Ultimately, more time is lost resolving conflicts manually, not to mention the increased risk of losing changes.

Certainly, if your business is aiming to be audited for its development processes, adopting a more controlled approach with tighter controls over who has the ability to package the source code, and also your mechanism to release it, is a must.

Opening up the Lightning Platform development process to tools such as Git and GitFlow, for example, allows for a much better developer interaction for aspects such as code...