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 software development process and life cycle.

As the code base grows and the number of contributions to it (at any given time) increases, it's important to monitor the quality of the code more frequently. Finding out that your Apex or Lightning Web Components tests are failing prior to creating a package version is frustrating and costly when you're trying to release the software to your customers. Continuous Integration works with a Source Control system to validate the integrity and quality (through your tests) of your application on an automated basis, often triggered by developers committing changes to source control.

In this chapter, you will learn about the following topics:

• Developer workflow
• Developing with source control
• Hooking up to continuous integration
• Releasing from source control
• Automated regression testing

This chapter and, in fact, the entire book tries to avoid being biased toward a particular operating system and only includes tools that run on most popular systems. However, at times, certain keyboard references or CLIs are used that may assume macOS is being used.