Chapter 13. Source Control and Continuous Integration

So far we have been making changes in the packaging 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 comes into play, mainly traceability of code changes and also the practical implications of conflicts when more than one developer is working in a development org at a time.

This chapter sees the packaging org take on more of a warehouse-only role, accessed only when there is a need to create a beta or release package and no longer for day-to-day development as we have been doing. This principle can become quite important to you and your customers if they desire that you demonstrate compliance and auditability with respect to controls around 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...

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 would be how to get it into a form so that they can start executing it. Salesforce provides a toolkit known as the Migration Toolkit that helps write scripts to deploy to a Salesforce org using the popular developer scripting language known as Ant. We will be building such a script in this chapter. Such scripts are also used by Continuous Integration build servers described later in this chapter.

The Migration Toolkit also provides a means to extract from Salesforce...

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.

In this case, we will be using the following tools to populate and manage the content of our chosen Source Control repository, in this case, 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):

• 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 from either https://desktop.github.com/. This chapter will use the Mac edition, though not to the level that it will not be possible find and perform equivalent operations in the Windows edition; both clients are really easy to use!

• Apache Ant v1.9 or greater: To determine if you have this already installed...

Hooking up Continuous Integration

So far we have been depending on the developer to ensure that the changes they push up to the GitHub remote repository do not cause regressions elsewhere in the application, by running Apex tests before making their commits. This is always a good practice!

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 over 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 that uses the Ant script to perform the build step. Before we get into setting...

Releasing from Source Control

When you're ready to release a beta or release version of the package for your application, you will transfer the source code from Source Control into your packaging org. Thankfully, this can also be achieved with the help of the following Ant script target. Note that unlike the deploy Ant target, this does not attempt to clean the target org!

<target name="deploy.package">
  <sf:deploy 
      username="${sf.username}" 
      password="${sf.password}" 
      serverurl="${sf.server}"
      runAllTests="true"
      deployRoot="${basedir}/src"/>
</target>

The process of updating the packaging org can only be partially automated by running the preceding Ant target, as you still need to log in to the packaging org to add brand new components that are not automatically added through a relationship with components already in the package.

The following is a list of recommended steps to update and confirm that the content of your packaging org matches...

Automated regression testing

While Apex tests are very much a key tool in monitoring regressions in your application, the limitations and scope of functionality they can test is small, particularly to perform volume or user interface testing (clients using JavaScript for example).

Note

You might wonder why the Ant script used by Jenkins deploys twice, as the check deploy to the packaging org will confirm whether the Apex code compiles and that all Apex tests complete successfully. The reason is that having the build org deployed with the latest build allows for it to go on to be used for other purposes, such as executing further regression testing steps.

Here are some considerations to implement further testing approaches:

• It is possible to execute the Apex code from the Ant scripts using the approach described earlier in this chapter, when we populated the developer org with sample data by calling the SeasonService.createTestSeason method. You can extend this approach by using loop constructs...

Summary

In this final chapter of the book, we have seen how to scale developer resources to 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 within a single packaging org or using other manual approaches to export and merge changes between developer orgs. Ultimately, more time is lost in resolving conflicts manually and 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 access to not only the source code but also your mechanism to release it (your packaging org) is a must.

Opening up your Force.com development process to tools such as Git for example allows for a much better developer interaction for aspects such as code reviews...