11 Things That You Cannot Do With Jenkins, And Never Will.
Change management is often used by companies to manage growth without the stress of the chaos that comes with it. With Salesforce development, change can come in several ways — a growing team, increasing number of sandboxes, more requirements and multiple releases happening in parallel. In the face of this complexity, developers are posed with the dilemma. How does IT maintain a thriving and fast-paced development and release management environment? What tool or solution would best serve to automate the change management process?
Jenkins, a continuous integration and delivery application to build and test software continuously, is a solution that generally comes to developers’ minds. It is free, it has a large plug-in library, it can be used across various platforms, and others are using it. While these may appear good reasons to consider it, it is important to look further into the horizon before you make a decision. Is this solution right for Salesforce and does it help achieve the objectives of the IT organization?
Experienced Salesforce release engineers are quick to point out that Jenkins, out of the box, is not useful. A number of plug-ins are required to get started and just use it as a build orchestration tool. Access control administration, ease of configuration and scaling are part of a growing list of challenges that developers and administrators run into.
So are your Salesforce needs being served by Jenkins? Here are eleven things for you to ponder on.
Establish proper release management processes: Jenkins is a continuous integration tool and not a release management solution. Continuous integration is a part of release management. However, enterprises need a complete change management framework which supports multiple processes and workflows to ensure collaboration, visibility, governance and compliance across the people, process and technology. Organizations need a comprehensive Application Lifecycle Management solution with the following capabilities:
- Manage Business Requirements
- Release Management capabilities
- Environment Management
- Version Control
- Testing capabilities
Analytics: Jenkins does not provide visibility into the end-to-end metrics. It does not communicate the key changes in the entire organization, or the challenges faced by the employees. Managers do not have insight into who are the most productive employees, what are the latest and greatest changes made to the production organization or any other change.
Solve salesforce specific issues: Jenkins is not made for Salesforce, and Jenkins does not understand Salesforce metadata types. For example, it cannot understand that some of the Salesforce metadata types are not granular and that they are not mutually exclusive. Also, there are many Salesforce-specific issues such as migrating profiles and permission sets from one organization to another organization. These problems cannot be handled by Jenkins, and the customer is responsible for making these migrations manually.
Governance: Customers using Jenkins have a lot of problems in the tracking and accountability of the changes made by the various members of the development team. Most deployments and builds done by Jenkins are done via a single, common user, making it unfeasible to track deployments. All the the traceability is only at the code level provided by the source control tool such as GIT.
Compliance: Customers need to ensure that they are meeting with the industry, geographical or department related regulatory compliance. For example, most public customers need to adhere to Sarbanes–Oxley compliance. This means that they need to ensure that they have proper access controls, segregation of duties and automatic change control, among other things, in place to ensure financial compliance. Other customers may require ITIL or COBIT compliance. Jenkins is not compliant with any of the aforementioned requirements.
Developer productivity: The key problem that Jenkins solves is automating builds on every code commit by a Salesforce developer. However, it does not increase user productivity by automating or streamlining every task in the change management process.
Collaboration and visibility: Jenkins does not allow developers to see the changes done by other team members. If a developer needs to understand the latest deployments to a given organization, he or she would need to reach out to the release manager or manually interact with other team members. Jenkins makes it really hard to track the changes by the entire development team.
Customizing the processes: Most customers have specific nuances to their application lifecycle management processes. While Jenkins provides continuous integration functionality, the framework cannot be customized beyond a certain extent. It does not allow the tailoring of the workflow processes, reporting, managing security changes and extensions to the base application to meet the customer’s needs.
Reducing Maintenance: Most customers need to install Jenkins on the local file server along with their local source repository. In addition, most customers have to write scripts to automate the release actions that Jenkins should perform. This greatly increases the maintenance. Most organizations have 1 to 2 developers to maintain the Jenkins framework.
End-to-end Environment management: Most large enterprises have many different sandboxes. They need a flexible application to track and manage the sandboxes including the purpose of the sandbox, refresh dates, owner of the sandbox, and more. Jenkins does not provide an agile framework to manage these sandboxes.
Certifications: Customers who select the Salesforce platform ensure that the platform meets their industry, financial and regional regulations. These certifications include, but are not limited to, ISO 27001, SSAE 16/ISAE 3402 SOC-1, SOC 2, SOC 3 (SysTrust), FISMA, PCI-DSS, EU/EEA and Switzerland Safe Harbor self-certification through the U.S. Department of Commerce, TRUSTe Certified Privacy Seal. Jenkins does not provide any of these certifications and, since many of the code changes are deployed using an uncertified platform, auditors can fail the certification for the entire platform.