Skip navigation
All Places > Developer > Blog > 2018 > February

One of the first things people do when they start thinking about implementing DevOps best practices is setting up continuous integration and continuous deployment (CI/CD) tooling.  So that’s just what we did with the Professor M School.  (Not sure what I’m talking about when I say the “Professor M School?”  Check out my earlier blog post Introducing Professor M’s School for Gifted Coders.)


We’ve set up CI/CD with not one but two popular tools:  Travis CI and Jenkins.  As you decide which tool to use, consider the following tradeoffs.  Travis CI is hosted online so you don’t have to set it up yourself.  Open source projects can leverage Travis CI for free, but closed source projects will have to pay.  Jenkins requires you to set up and manage the app yourself but is free for all projects.  


Travis CI Build
Automated build inside of Travis CI.


Jenkins Build

Automated build inside of Jenkins


We’ve set up the same basic flow for both CI/CD tools:

  • Run the automated tests
  • Build the Professor M module loadable packages


In addition, the Travis CI build is configured to post the Professor M module loadable packages to the GitHub releases page whenever a commit is pushed to the master branch.


You can learn more about how we’ve implemented CI/CD in the Professor M School’s Readme:


You can also explore the results of our latest Travis CI builds at


We hope you’ll be able to leverage the work we’ve done to setup CI/CD with Travis CI and Jenkins in your own projects!   

One of the biggest pains in developing a module loadable package for Sugar is figuring out how to track the package in source control.  You don’t want to keep your entire Sugar directory under source control--you just want your custom code in source control.  However, from a development perspective, this can be a huge pain.  If you do your development separate from the Sugar directory, every time you make an incremental change, you have to manually build and install the module loadable package, which is a process that can quickly become very time consuming.


We’ve developed a tool you can use called the Sugar Synchronizer.  The Synchronizer allows you to develop your Sugar customizations in your Sugar directory while still tracking your changes for your module loadable package in a separate directory.  You can see a live demo of the Sugar Synchronizer in the Sugar Winter '18 Technical Training

webinar recording (you may want to jump ahead to the 38:42 mark).


The Sugar Synchronizer is open source, and you can get a copy of the code in our GitHub repo:  The repo’s Readme has instructions on how to use the Synchronizer.


If you have suggestions for improvement or find a bug, please create an issue in the GitHub repo.  Or, better yet, write some code and submit a pull request!  


We hope the Sugar Synchronizer makes developing module loadable packages easier for you!

We’ve been working behind the scenes to create a customized version of Sugar that we’re calling the Professor M School.  The essential pieces are ready to go, and we’re thrilled to announce that the repo for the Professor M School is now public and open source.  


So what is this the Professor M School?  Let’s begin by talking about the goals for this app:


  1. The app should be an authoritative example on upgrade-safe customizations.  We want you, the Sugar developers, to be able to use this app as a reference for what good, upgrade-safe customizations look like.

  2. The app should provide examples of DevOps best practices when developing Sugar customizations and integrations.  For example, we want to have examples of automated test suites and how to leverage continuous integration tools.

  3. The app should include common customizations so that SugarCRM’s engineers can use it for testing and validation.  When our engineers want to know if their changes are going to break common customizations, we want them to be able to use this app to find out.  Ultimately, we want to integrate the app’s automated tests into our internal continuous integration process.

With those goals in mind, we developed the scenario and use cases for the Professor M School.  The app is built around a fictitious university called Professor M’s School for Gifted Coders.  If you attended UnCon 2017, you might remember hearing about Professor M.  We’ve built on what we created for UnCon in order to create the Professor M School.  

Let’s talk about the scenario behind the Professor M School.  Professor M aka Professor Marum has created an exclusive not-for-profit school for gifted coders.  The school currently uses Sugar for the following use cases:

  • Managing applicants, current students, former students, and professors
  • Tracking super groups affiliated with students
  • Soliciting donations from alumni and alumni affiliated super groups.

Professor M will be expanding his use of Sugar to cover other use cases in the future.

To learn more about the Professor M scenario and see a demo of the customizations, check out this video I previously recorded (you might want to jump ahead to the 1:07 mark).

As I mentioned earlier, the Professor M School is open source.  Here are some ways that you can get involved:

  • “Watch” the Professor M School’s GitHub repo:
  • Explore the code and use it as a resource as you develop your integrations and customizations.
  • Submit GitHub issues if you have ideas for improvement, a feature request, or a bug report.
  • Update the code and create a pull request.


We hope you find the Professor M School to be a useful resource!  Check back soon for more updates on the app!