The Kremer Prize was established in 1959 to award 50,000 British pounds to the team that could create the first human-powered flying machine. Continuous Development (CD) is now being applied to software development, including Salesforce, to build and deliver high-quality software quickly.
With this article, learn about the history of the Kremer Prize and how Dr. Paul MacCready's approach to building a human-powered flying machine can be applied to software development through Continuous Development. The article also provides tips for Salesforce developers to implement Continuous Development, including the use of source control, automated testing, and a CI server.
Here are our 5 Key Takeaways:
1. Dr. Paul MacCready's approach to building a human-powered flying machine can be applied to software development through Continuous Development.
2. Continuous Development requires each developer to commit changes into a central shared code repository several times daily and to automate the build and deployment process.
3. Salesforce developers can implement Continuous Development by using source control, running tests automatically, and running a CI server.
4. Automated testing is a key component of any Continuous Development pipeline, including unit testing and functional testing.
5. Blue Canvas is a source control and push-to-deploy tool for Salesforce apps that can simplify the Continuous Development process.
Henry Kremer was a prominent industrialist in 1950s Britain. As was his right as a prominent industrialist, the man was rather eccentric. The object of his obsession was human powered flight. So in 1959 he established the Kremer Prize which would award 50,000 British pounds to the team which could create the first human powered flying machine.
The course was simple: make a figure eight around 2 markers spaced a half mile apart while maintaining a height of at least 10 feet. Despite over 50 official attempts and 17 years, no one was able to claim the 50,000 pound prize (equivalent to approximately $1.4M today).
Optimizing for Speed Then, in 1977, Dr. Paul MacCready stepped up to the plate. He immediately realized that the problem was not “how do I build the first human powered flying machine” but instead, how do I build an airplane which can be assembled in a matter of hours rather than months.
You see, most teams had long design phases. They would spend months designing their planes. They would then go through another few months building the plane to precise specifications. After months of work they would run their test and inevitably crash the plane. They would then start the month long cycle again. Sound familiar?
MacCready instead built a plane out of mylar and Scotch tape . The plane could be rebuilt in a number of hours, allowing him to test the design on a daily basis. Whereas most teams did one or two flights a year, MacCready’s team did 222 in 6 months. On the 223rd he claimed the prize.
The problem was not to build the first airplane, but instead, one which can be assembled in a matter of hours rather than months. Continuous Integration (or Continuous Development) Many are applying MacCready’s lesson to software development with the advent of Continuous Integration (CI), Continuous Deployment and Continuous Delivery (CD). We prefer the term “Continuous Development” to account for the fact that an effective implementation of CD has to support each step of coding, building, testing, and releasing software.
Continuous Development requires that each developer commits their changes into a central shared code repository, several times daily. Their changeset is tested and verified by an automatic build system, which allows teams to detect problems early on. If all tests succeed, the updated app can be then packaged and deployed immediately rather than after a lengthy software design and integration period.
To practice CD, teams need to work on a single optimized build pipeline. This pipeline embodies a number of important principles and components:
Maintain a single repository for your source code Code by cloning the repository into your personal environment Automate the build and deployment process The code must test itself Everyone can see changes and compare environments It must be possible to roll-out and roll-back quickly and transparently This is achieved by setting up a number of different tools, like source control, test and build automation, and deployment tools.
Why Continuous Integration matters for Salesforce? For many organizations, CD has become the standard way to build and deliver high quality software. Because integration and testing is automatic and happens so frequently, the chance of discovering errors late in the release process is reduced dramatically. The shortened periods between introducing a bug and noticing it make is radically simpler to find and fix a problem. Not only can developers now focus on building stuff, it also eliminates the time wasted on manual testing or waiting for deployments to finish.
Developers can focus on building stuff and eliminate the time wasted on manual testing and waiting for deployments. Even our friends at Gartner believe that the cultural and management shift in organizations toward a DevOps approach (which includes continuous delivery, continuous improvement, infrastructure and configuration as code, and so on) offers strong growth opportunities for DevOps toolset vendors , as well as the teams adopting them.
What Continuous Integration can change for Salesforce Developers This is especially true for Force.com developers. The Force.com platform is a wonderful and powerful thing. Tools like Lightning, Apex and Visualforce are designed to build full-featured custom Salesforce applications quickly.
But if you can’t deploy your code as quickly as you write it, you are missing out:
Your users count on your software to get their jobs done. Force.com applications empower hundreds of thousands of people around the world to do great things. The longer it takes to deploy new features to them the less effective they are. Bugs in applications built with Apex, Visualforce, and Lightning are measurable and extremely costly. If your sales team is getting paid millions of dollars and a bug prevents them from doing their job, the downtime costs your company dearly. You’re writing awesome features and beautiful code. Why leave it on the shelf or create a perception of mind-numbing bureaucracy? Get it out there! Roll out Continuous Deployments for Salesforce With all the benefits CD brings to the table, it can be surprisingly hard for Salesforce developers to implement. Due to the cloud-hosted nature of Apex and Lightning, it’s challenging to set up and maintain a well-functioning, performant and reliable toolchain. It requires some training and expertise to pick the right tools, and bring them together in a working process. Here are some tips for getting started:
Use Source Control Version control or source control is absolutely essential for anyone looking to do continuous deployment. Tools like Git, Team Foundation Server, or Perforce do the job here. There are a number of hosted services, like GitHub , Bitbucket or GitLab which save you the manual set up. Source control allows you to track changes and collaborate much more effectively.
Something particularly important to the Force.com community is source control of code on your actual Salesforce Orgs.
What happens if multiple developers work on the same project; one developer updates a class, while shortly after, another developer saves changes to the same class?. How is merging the code handled? Unfortunately today, there is no good answer for this. The changes would be overwritten and irrevocably lost. (Hint hint: this is where Blue Canvas aims to help!)
What happens if multiple developers work on the same Org? How are changes to the same class merged? Run Tests Automatically Automated testing is a key component of any continuous delivery pipeline. Automated testing usually takes two forms: unit testing and functional testing. Salesforce applications need both.
Your unit tests are small, quick atomic tests that allow you to test individual components of an application. Salesforce mandates code coverage of at least 75% of Apex code , else it cannot be deployed to production. The tests are typically written in Apex test classes, but are only run by Salesforce during a deployment or if manually triggered. To trigger them automatically as part of your CD toolchain, additional tooling is needed. The Force.com CLI utility, written by the great folks at Heroku, is our weapon of choice here.
The second component is functional tests. These are also sometimes called integration tests and allow you to test how the entire system is working end to end from the database to the front end. Tools like Selenium are great for this and third party services like Sauce Labs make it easy to get started. If you are looking for an end-to-end solution, check out Cinnamon , a testing framework written and maintained by Salesforce, that integrates with Sauce Labs out of the box.
Run a CI Server Now, to tie everything together, you will need a CI server as a build engine. The CI server is the conductor of the orchestra. It polls your source code repository for changes and executes whatever steps you have determined are important for your delivery pipeline when it finds new commits
There are plenty of tools to choose from, but here are some good ones to check out:
Travis CI – a popular hosted service with YAML based build configurationJenkins – the classic open source CI tool which has recently seen new updatesBamboo or Bitbucket Pipelines – Atlassian’s professional CI/CD tools with excellent integration into their whole product suiteWe want you to spend time coding Setting up CD for Salesforce is difficult. It’s a complex, cumbersome process that has you connect different tools and systems, just to get the bare minimum working. Many organizations spend years designing and perfecting their delivery pipeline. And then they spend months to fix it and maintain it.
We believe your time is best spent building awesome apps. Make bold changes. Think big. Work together. Let us do the heavy lifting and waiting. Blue Canvas is source control and push-to-deploy for Salesforce apps. We think this is how easy it should be:
$ git push salesforce master
What do you think? We want to understand your vision for what your continuous delivery pipeline should look like. Imagine how awesome it will be when your morning’s code changes are live and in production and getting used by actual users by the time you’ve made your 11am cup of coffee. Imagine the smile on your team’s face when you are able to quickly release a patch for a bug in 15 minutes.
Once you’ve seen the vision, the rest is just details.
Get in touch: team@bluecanvas.io
