Why Adopting CI/CD Will Improve Your Team’s Job Satisfaction
In any field, professionals just want to do their job well to deliver results and impact. Usually, that satisfaction comes from the knowledge that goals are achieved, and problems are solved.
Every industry has its own challenges and ways of measuring whether a job is being done as well as it possibly can be. Within a DevOps culture, the challenge is to shorten the development life cycle while delivering the required quality software by following an iterative process.
While it may be possible to accomplish that in different ways, one of the best ways is by adopting Continuous Integration & Continuous Delivery (CI/CD) practices.
At this point, most people in software know the benefits of CI/CD, but I suspect not everyone understands the intangible benefits. The tangible benefits of quality, speed, and collaboration have been widely discussed and documented on the web. I have not found, however, a lot of material on how CI/CD benefits the organization from the ground up.
Of course, CI/CD is about providing regular checks, detecting errors, and releasing quality code. But it’s also about improving the health of your entire organization and increasing employee/developer satisfaction.
Here’s what happens when you adopt this practice:
CI shortens the life cycle of bugs, giving developers more time for strategic projects.
That’s longer than most of us like to wait before fixing a problem in our code. And unfortunately, those mistakes sometimes make it all the way down the chain before they’re sent back to the developers to solve. The is problematic because it’s often difficult for developers to keep track of something they did a week or two ago. Suddenly, they’re expected to stop what they’re doing and revisit work that’s not fresh in their mind.
A developer should be able to input their code into the system and learn whether they checked in bad code within 24 hours or sooner. This ability is exactly what you get when you adopt continuous integration practices. Overnight, a functioning system performs or runs tests to ensure accuracy so when something fails, it’s almost always evident by the following day—not the following week.
If you give your IT team the ability to immediately figure out when something is wrong with the code, they’ll learn to make fewer mistakes. And, crucially, they’ll have to spend less time fixing those mistakes.
Less time spent editing code means there’s more time available for working on the strategic projects that are essential to your company’s success.
Developers gain more confidence and coding discipline.
Just as writers use style guides to keep their work uniform, developers also have parameters that describe the best way to write code.
Ideally, once a developer writes a piece of code, he or she will describe it in detail so that the next person who looks at the code will understand how to work with or around the method. In practice, this doesn’t happen very often. Developers hate documentation. Any developer worth their salt will view it as a secondary—and hence, unnecessary—part of the job. I’d say less than half of all developers actually create documentation.
That means you can inevitably expect some resistance to the documentation and processes continuous integration require when you first adopt it. But once your team sees the benefits of following the CI guidelines—documents become much clearer, coding discipline improves, developers gain confidence, and the code gets to end users faster—it will be easier to get everyone on board.
Initially, CI practices may seem burdensome, but putting in the documentation work will lead to a healthier organization as coding discipline increases.
As your team develops better processes, your entire company improves.
Unlike other industries, the tech industry is human capital driven and the best way to accelerate is to improve the human capital. Companies spend a lot of time and money on planning perks, benefits and systems to ensure higher retention, hiring, and improving the morale and satisfaction of their employees.
Advantages of implementing/adopting CI/CD processes is that benefits are not strictly technical. Yes, the code gets to end users faster and bugs are caught much earlier. But those technical aspects will actually boost team morale and increase your developer’s satisfaction as well.
When a developer knows that the CI/CD system will kick back issues the next morning, they gain confidence. They know their work will go live faster. They know they are creating and not maintaining code, meaning they won’t have to backtrack and work on the same code they were working on two weeks ago when a bug is finally caught. And they know they won’t have to burn the midnight oil on a Friday evening before the software is deployed.
This increased satisfaction has a cumulative effect. A happy team makes recruitment much easier, which in turn improves the talent on the team. As you gain more talented individuals, the overall health of your company improves. Management spends less time worrying about morale and improving coding discipline because the CI system itself is helping to build better code and a happier organization.
No other perks can replace this sense of employee contentment, (otherwise, ALL the high-flying and heavily-funded startups would have succeeded). Of course, perks help, but job satisfaction for a professional is the visible proof that he is contributing value to his organization. A software developers’ true satisfaction is to solve a problem and validate that their piece of code reaches the customer/user quickly and the customer/user is using the feature that was developed, with ease
The tangible benefits (of this intangible value) are satisfied employees, greater retention, and improved bottom-line.
All that leads to increased job satisfaction among the professionals on your team, which is the holistic aspect of continuous integration adoption that is rarely talked about. But it’s arguably just as important as the technical implementation when it comes to the health and happiness of your company.
Vishnu Datla is founder and CEO of AutoRABIT. You can follow Vishnu on twitter @vishnuraju
DevOps: What is it and why should you pay attention?
What is it?
DevOPs is a buzz word that is so often tossed around within the software development industry. However, very few people understand what this concept means and the implications that it has on the way software is developed. So, what is DevOps? In simple terms, DevOps is the practice of integrating operations and development teams to improve collaboration and productivity throughout the entire service lifecycle, from design through the development process to production support. The keyword in that definition is practice. It is important to note that DevOps is not a tool but a culture; a mindset. It is the collaboration between development teams and operations teams that ensures that an organization can deliver applications and services at high velocity. The goal of a DevOps practice is to enhance a business’ ability to better serve their customers and compete more effectively in the market.
Why should you pay attention?
IT-enabled innovation is a competitive differentiator for almost all types and sizes of organization. The aim of DevOps is to break down the silos that separate Developer teams and Operations teams so that there is better collaboration between both. Companies that successfully incorporate DevOps into their operations typically win in the marketplace. For this article, let’s consider three key ways that a company wins:
- When you think of DevOps, think strategic initiative. When executed correctly, DevOps can help to drive business growth and build value for all stakeholders. It does this by enabling companies realize significant benefits in the three components of ROI. These include reduced costs, enhanced productivity and faster time to revenue.
- Furthermore, imbibing a DevOps practice can help organizations to increase agility in delivering IT systems, and improve time to market. The ability to deliver software rapidly lends competitive advantage.
- Finally, DevOps ensures that businesses can focus on automating the entire development process. The impact of this is that organizations can develop and run software reliably and cost effectively.
Our verdict
At AutoRABIT, we believe that DevOps is the future and we are excited about adoption success stories across various industries. For example, within the financial industry, Capital One is a shining example of DevOps done right. It is not secret that customers demand streamlined, fast and smart banking services. In response, Capital One uses data, technology, and data science to form their strategy, in designing financial products that are based on things like lifestyle and customer need. For Capital One, banking needed to be real-time, intuitive, intelligent and anticipatory of customer needs. Having had a successful Agile practice, DevOps was the natural next step in their strategy for channeling data and intelligence in terms of understanding the customer and anticipating their needs. Read more about how Capital One is using DevOps here.
Continuous Integration vs. Continuous Delivery for Salesforce…and Why You Should Care
Let’s start with defining these terms first.
Continuous Integration (CI): The practice of frequently merging all developer working copies to a shared mainline.
Continuous Delivery (CD): Aims at building, testing, and releasing software faster and more frequently by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for Continuous Delivery.
…and if these definitions aren’t confusing enough, let me add the third term: Continuous Deployment. Continuous Deployment means that every change is automatically deployed to production.
So, why should you care, and my favorite answer is “Release Velocity“. Let me explain.
Remember, when you wrote your first big code (the one after “hello world” J), you compiled it and voila, you saw the results. But then your colleague said: “Did you test it?” So, you thought of various use case scenarios and created tests and ran it. But then your user said: “I want to test it myself.” By the time you got your user feedback, you already wrote 3 new features. Repeat this for 2-3 more cycles and suddenly you realize there’s a mess and it’s increasing exponentially. So you decided to have a separate development/test environment (sandboxes) and a production environment.
Now, let’s say there are 20 more developers like you in your team; you end up with 20 parallel sandboxes. So, you introduce a Version Control system and decided to have a Release Manager to manage these releases into one product release. This ‘mess’ is more common and more exasperating, since I am, of course, oversimplifying…but hopefully you get my drift.
The point is that a significant chunk of development cycle is spent on managing this code(s) vs. writing that code, and CI/CD helps you ease that pain. In fact, we, at AutoRABIT, assert that the entire release cycle can be done with just a few clicks of the button.
Let’s look at key functionalities required to achieve this:
- Version Control: prevent overwriting of each other’s code
- Sandbox Management: synchronize multiple environments
- Deployment Automation: remove manual deployment steps with ability to rollback
- Test Automation: Run functional, Integration, Regression, UAT and other tests automatically.
Once you implement CI/CD as a practice, two things happen:
1) all issues with code integration across multiple sandboxes reduce dramatically and
2) developers spend more time writing code vs. managing bugs.
The end result is a faster release cycle or a higher release velocity.
If you are still with me, I’d like to recommend two sessions at Dreamforce to help you learn more about CI/CD. The first is a Panel Discussion (Moscone West Room#2004) between CI experts, who describe the concepts of CI/CD and discuss their real life experiences on implementing CI for their Salesforce deployments. It is scheduled on Thursday, Oct 6th at 3 pm (at location name hall number). The second is a theater session where we talk about CI: Best Practices, ROI & Business Case (Moscone West, Mobile Theatre). We also bring along our customers, who have our largest subscriptions; they will describe their real life experiences as to how they achieved Salesforce Continuous Integration. It is scheduled on Friday, Oct 7th at 8:30 am (at location name hall number).
If you are thinking about starting on Salesforce Continuous Integration or are in the middle of implementing CI in your Salesforce deployment, attend the sessions and, come and meet us at our Booth#9 at Developer Forest at Dreamforce 2016.
We are very excited about CI/CD and look forward to meeting you there.
Salesforce Continuous Integration – What is not explained !!
DreamForce 2016 has 900+ Salesforce Customers, Architects, MVPs spending their valuable time on Salesforce release management at AutoRABIT Booth in Devzone and it was some experience !!!.
We could divide the Salesforce fraternity that visited us at the booth into three segments :
- Clients who were not sure where to start the whole thing and the amount of knowledge and expertise required to make the journey successful
- Clients who have used some tools but did not reach the level of automation or scalability to the extent they anticipated
- Few Architects and experts, who were able to assess the current state of Salesforce Continuous Integration and were able to visualize a wishlist for future.
With a much bigger and awe-inspiring DreamForce’16 making its way in few weeks, it was very important to assess AutoRABIT in three segments and to ensure we have a release that announces itself in such a way that answers most of the challenges from the Salesforce World with respect to CI and release management.
The result is the much awaited AutoRABIT 4.0. Considering it is a pre-cursor to DreamForce and we know the hype and expectations around it , this has been one of the biggest release ever from AutoRABIT.
The first of the AutoRABIT 4.0 blog series is to outline the thought process and the problem areas that went into the brainstorming of the release.
The unexplored territories in Salesforce Continuous Integration
- 360 Degrees view for Salesforce Continuous Integration – Salesforce CI is not just about deploying some changes from a GIT branch into Salesforce Sandbox using tools like Jenkins. It needs lot more support from tooling to achieve 360 degrees Salesforce CI for Check-in, Merge , Deploy seamlessly.
The following are some of the items that need to be looked at on how the current tooling is letting down the vision of a Salesforce CI practitioner in achieving higher maturity in the company with release automation.
- Developers should be able to check-in their changes into a Dev Branch effortlessly without crypticness associated with a version control system.
- Check-in mean that Developers take the entire metadata file [ a profile or a custom object] from their Dev Sandbox using Mavensmate or Eclipse, overwrite the file into a GIT clone and push it into a common GIT Dev Branch.
- Most developers miss out on the fact that they must check-in Layouts, Profiles etc., when they a create a custom field and just what they worked on and there is no way to detect any of these missing dependencies apart from a bug identified by QA members
- Does any of the CI tools understand the salesforce parent-child metadata concept or the problems with Profiles or Custom Labels being the largest shared files which keeps getting modified for other changes.
- Pushing the check-in information into ALM so that user story and metadata are associated for easy reviews and sign-offs is another challenge and release managers even today maintain large excel sheets “asking” for what the developers worked on to be maintained in a separate sheet.
- Release team should be able to easily cherry-pick / merge what goes into the release as all user stories may not make the cut.
- Merge is not just about integrating two branches. There needs to a branching strategy behind it.The decision of feature branches Vs common Dev branch for the entire team needs to be discussed at depth.
- GIT tooling support is that not great when it comes to merging a set of changes [ group cherry-picking ] easily from a branch into another branch. It becomes a hard task for the release team to be able to cherry-pick a group of commits for completed user stories and merge them into a higher release branch.
- GitHub, BitBucket doesn’t support cherry picking in cloud – need to install a client tool like GitHub for Windows or SourceTree or TortoiseGIT.
- SourceTree doesn’t support grouped cherry-picking – TortoiseGIT supports it.
- Conflict resolution – the less we talk about it, the better if I am Salesforce adminstrator.
- The editors like SourceTree doesn’t support merge changes from both source and destination. Its either local or remote incase of a conflict block.
- Tagging a group of commits to a release and deploying them is looked as too far dream with the tooling around.
- Deployment – Deployment of changes from version control to Salesforce Sandbox is not just about using an ANT script and calling a Jenkins Job. It is about lot more things in Salesforce Deployment.
- Deploying an entire branch from GIT will inevitably result in “Too Many Files” issue due to Metadata Governor limits .
- How this often ends up is that Salesforce teams stop committing the profiles, custom objects etc., to GIT and end up with code items which is not the right spirit of version control.
- There should be a support for deployment from a particular baseline revision or able to deploy a hotfix commit directly from version control.
- Support for not just GIT – Several large enterprises use SVN, TFS , Perforce and the Salesforce CI is not just about GIT.
With AutoRABIT 4.0 , we are proud to announce 360 degrees support Salesforce Continuous Integration with its check-in editor, Merge Editor and rich deployment support.
2. Profiles, Profiles and Profiles
There has been a lot of talk and experimentation being done around managing the profiles. Administrators have tough time deploying the profiles, Governance teams have tough validating profiles and Architecture team to set rules for what should be excluded in Profile Migration and ensure they are met by the development teams.
The fact remains that Managing Profiles has been a primary challenge for Salesforce teams across the globe.
With AutoRABIT 4.0 , we are pleased to announce a Profile Designer to check-in, Compare and Deploy the profiles across multiple sandboxes that gives you full control over the Profile Management.
3. Manual Steps in Salesforce Metadata Migration
Inspite of ANT which is at best a handy tool for for migration or changesets, it is still a case of heavy manual operations post migration.
It could be items related to updating email addresses , creating groups, updating scheduled jobs or it could be items arising out of using unsupported metadata in migration.
AutoRABIT 4.0 is the first ever tool to introduce a framework for automating pre/post migration steps in Salesforce migrations.
4. Salesforce Release Management is not just about Metadata
While Salesforce CI is often circled around metadata migration , which is only addresses a part of the challenge faced by Salesforce administrators. Setting up environments with the data of the important objects with least effort is often left as manual exercise or needs to have another set of tools doing the job.
While it is known that AutoRABIT has a rich integrated Data loader , it has just become even better with 4.0
5. Test Automation
AutoRABIT 4.0 has enhanced its Test Automation Factory model to revolutionize test automation with enhanced support lightning and Salesforce appexchange components.
6. CI Adoption and ROI justification
While Management teams invest in huge time and money for innovation and automation, a big challenge for them is to able to monitor, measure and visualize the adoption rate of automation and the ROI benefits associate with it.
AutoRABIT 4.0 has a reporting module that gives a holistic view of metadata deployments, data migration, CI results, test results etc., giving complete picture of CI adoption and ROI reports.
If you think these are the challenges that you are looking to address in your company in pursuit of Salesforce release automation, scheduled a discussion with us at Sales@autorabit.com , with your problem statement and we are happy to assist.
I will follow-up this blog with a detailed feature walk-through of AutoRABIT 4.0 .
Continuous Integration: 5 Best Practices
Repeat after me, Continuous Integration is a practice and not a tool. There! #mindblown.
Now let’s move on. Like every practice, implementing a successful Continuous Integration (CI) practice within an organization requires discipline, particularly when your development environment contains a significant amount of complexity. Best practices are methods or techniques that consistently bring superior results. Ready for the best that CI has to offer?
Here are 5 CI best practices:
Version Control is your BFF…hang out!!!
The best way to manage source code, files, data and metadata is to use a version control product. This will ensure that there is a complete audit trail and history of the code, along with changes and updates made to it, when and by whom. It’s also the place where the build server can monitor the code to determine any changes.
Got version control? Use it!
Test groups and configuration files are similar to source code in that they change frequently and need to be audited and traced. They should be kept in the version control system. That way, teams can revert at any time to previous versions of the code for comparison.
Commit frequently…like all day long!
Continuous integration won’t be continuous integration if you did not commit changes and integrate them on a regular basis. Once a day if you want to build just OK software and several times a day if you want to build AWESOME software. Frequent commits allows teams to detect problems early and locate them more easily. This makes it possible to know the real time state and health of the software.
Build fast…like under 10 minutes fast
With Continuous integration, builds should be fast. Anything beyond 10 minutes becomes a dysfunction in the process, and we don’t want that. Therefore, commit frequently, and build frequently. Large builds should be broken into multiple jobs and executed in parallel.
Automate deployments
With automated deployments, teams can release valuable features to their users more often and in incremental steps. This practice is at the heart of continuous deployment and automated deployments make it easy to deploy software at the push of a button. Frequent deployment ensures that the development team can gather continuous feedback from users on the software they are creating and adapt their approach as a result. This feedback can be the difference between a product delighting its target audience or missing them completely.
If you want to know more about how AutoRABIT can help with the implementation of Salesforce Continuous Integration, ask us for a FREE TRIAL
Powerful Salesforce Continuous Integration with AutoRABIT
AutoRABIT for Powerful Salesforce Continuous Integration
Summary
Continuous Integration and Continuous Delivery of applications are essential for higher release velocity and faster go-to-market. With development teams working on multiple parallel releases and multiple Salesforce environments, Version Control is essential for the development teams to maintain isolation, parallelism and change analysis in their development and release process.
AutoRABIT has some very powerful capabilities that can help Salesforce development teams get onboard and streamline their development process with Version Control System. It also has some unique CI capabilities that can keep your deployment footprints lean and also have automated test execution, code coverage, static code analysis enabled as part of CI deployments.
This article talks about the Salesforce Development Environment challenges and why AutoRABIT is the best with its powerful framework for achieving Salesforce Continuous Integration.
Salesforce Development Environment
Salesforce developers can work on individual development sandboxes or share a common development sandbox based on the Salesforce licenses purchased by their enterprise. Developers make configuration and code changes to the key standard objects such as Account, Opportunity, as well as to custom objects as part of their development effort in multiple sandboxes. The security settings on various application components are maintained through a set of profiles in Salesforce.
The release process constitutes migration of changes across multiple release environments, viz., QA/SIT, UAT, Pre-Production and Production. There are some steps to be performed before and after migration of metadata in Salesforce.
After every production release, it is a practice by Salesforce teams to refresh their Sandbox environments to keep their developer and release environments in sync with production.
Challenges in Development
-
- Multiple Development Tracks: There are several project teams, viz., Sales, Service, Marketing, etc., working with deliverables for minor and major releases. Consolidating all these changes from multiple development teams without stepping on each other’s shoes is a challenge, as metadata, such as profiles and permission sets, are shared for various development tracks.
- Multiple Releases: There are minor releases (config only), major releases (quarterly once) and hotfix releases for any business critical issues that happen simultaneously. Ensuring the development and release environments are in sync constantly across these releases is a challenge.
- Multiple Environments: There are quite a few environments such as SIT, UAT, Performance, Training, Innovation, etc. Maintenance of these environments is a challenge, especially with many pre-refresh and post-refresh activities that need to be done manually after every production release.
- Complex Salesforce Orgs and Heavy Deployments: Salesforce environments are large and complex with large custom objects, profiles and permission sets, and typical deployments contain few thousands of members.
- Governance and Audit for Deployments: Several types of releases happen in parallel and changes are directly made in release environments such as SIT, UAT, which make it difficult to track the changes from a governance and audit perspective.
- Environments Out-of-Sync and Challenges with Refresh: Since changes happen directly on Salesforce environments during releases and some of the BRs may not go-live to production, being rejected in the UAT phase, the developer sandboxes, release environments and production orgs are out-of-sync. Frequent refresh causes developers to lose their work-in-progress as well as induces a lot of manual steps for the development teams.
- Lack of Version Control: Since multiple development tracks happen in parallel, changes to shared metadata members such as Custom Objects and Profiles happen, resulting in overwriting of code. It is not possible to maintain versions of changes, track them and roll them back in the Salesforce environment.
- Manual Steps in Migration: There are many pre-migration and post-migration steps involved in deployments in addition to large deployment footprint.
- Exclusion Lists in Deployment: Security guidelines and architecture recommendations can require certain metadata to be excluded in packaging and deployments. Examples include login IP ranges, SSO configurations, etc. There is no way to skip parts of metadata in current deployment process without heavy manual intervention.
The Benefits of Version Control System (VCS)
-
- Team Collaboration: Developers can check-in their changes to Version Control System and can share it with other members of the team so that they can constantly keep their environments in sync and also be able to perform code-review process on the changes with mechanism such as “Pull Requests”.
- Change Analysis: Version Control System gives the ability to track various versions of the changes made to a file. It ensures the team is always able to look at application as a series of changes and in case of any bad fix, they can track, isolate and revert the changes done to the metadata.
- Streamlined Release Management: With multiple releases happening in parallel, the application needs multiple levels of isolation to support development phase, release activities and maintenance mode in case of any hot fixes to be delivered. With efficient branching and merging techniques available with Version Control, it would be seamless to maintain multiple versions of the software efficiently and support parallel development.
Salesforce Metadata Structure
Salesforce metadata can be retrieved from Salesforce into local filesystem as well as deployed into Salesforce with its Metadata API. The metadata of the Standard as well as a custom objects are in XML file format.
Typical Salesforce Object Metadata Structure is given below:
Note: As you can see a Custom Object Metadata definition, along with all the child metadata, such as Custom Fields, Validation Rules, Sharing Model, is all stored in the same flat XML file in Salesforce.
Salesforce Metadata Constraints Force.com IDE for Version Control
Traditionally, even though developer works on his sub-metadata type like a custom field, when they request Salesforce from any tool, such as Eclipse, the entire Custom Object will be retrieved from Salesforce. Hence, when the developer pushes the changes to Version Control, the entire Custom Object is available for the check-in. This Custom Object can contain the changes done by other developers on this object metadata, which may or may not be eligible for check-in to Version Control System such as SVN/GIT.
It will put additional challenge on the developer to review all the metadata XML files for changes and edit them from his workspace, before he can send the changes to Version Control System.
Here are the metadata components whose children are also metadata, but are embedded in the same XML file as the parent metadata.
| Parent Metadata | Child Metadata |
| AssignmentRules | AssignmentRule |
| AutoResponseRules | AutoResponseRule |
| EscalationRules | EscalationRule |
| CustomLabels | CustomLabel |
| CustomObject | CustomField
BusinessProcess CompactLayout RecordType WebLink ValidationRule SharingReason ListView FieldSet |
| MatchingRules | MatchingRule |
| ManagedTopics | ManagedTopic |
| SharingRules | SharingOwnerRule
SharingCriteriaRule |
| Workflow | WorkflowFieldUpdate
WorkflowTask WorkflowAlert WorkflowSend WorkflowOutboundMessage WorkflowRule |
Benefits of AutoRABIT EZ-Check-ins
-
- Check-in Only My Changes: With AutoRABIT EZ-check-ins, developer can retrieve the changes up to the last child metadata type (such as changes to custom fields, validation rules, etc.) that he/she has worked on and submit the changes to VCS instead of pushing the entire object.
- Append Vs Overwrite: AutoRABIT will logically append the modified metadata based on the change done to the file system in VCS, ahead of traditional overwriting of the entire XML file from Salesforce sandbox.
This can ensure metadata components, such as Login IP Ranges, etc., from developer sandbox will not overwrite what is in VCS.
- Dependencies: AutoRABIT EZ-check-ins shows cases of all the dependencies to be checked-in for a particular change.
For e.g., creating a new custom field will have impact on Profiles, Layouts, etc., and AutoRABIT will list all these members to be checked-in, along with their timestamps.
- No Additional Tools/Training: With AutoRABIT EZ-check-ins, there is no need for training on Version Control Systems, no need for additional tools such as GIT/SV/TFS clients and understanding of complex CLI of these tools to perform the check-ins to VCS, as check-ins can be done from right inside AutoRABIT in your browser. Hence, it is easy to on-board Version Control and CI journey easily with AutoRABIT.
- Tag the Changes to User Story/BR: With EZ-check-ins feature, developer can associate his metadata changes to the BR or user story in his ALM.
Challenges with Traditional CI for Salesforce
-
- Maintenance of the Build Scripts
- The packaging and deployment scripts are to be written using ANT Migration Tool and it needs to be maintained for each new Salesforce release to update/remove the metadata types added/changed in the Salesforce release.
- The scripts are also not robust and flexible, where we cannot retrieve changes based on a “modified date” or by a particular developer.
- If the changes are to be retrieved from VCS such as GIT/SVN, it would mean that additional knowledge of the CLIs of version control tools are required to maintain the scripts maintained.
- Using the scripts, we can deploy the entire changes of a GIT/SVN/TFS/Perforce branch into Salesforce but cannot deploy “Cherry Picked Commits” or changes from a particular baseline revision instead of the entire branch.
- Maintenance of Destructive Changes and Wild Cards in scripts are additional overheads.
- Large Metadata Deployments: The file size of Metadata components such as Custom Objects, Profiles can be really large.
For instance, even though only one Custom Field is modified in a particular release and is checked-in into VCS such as GIT, the check-in will be made into the Custom Object file. Hence, as part of the deployment, the CI job will deploy the entire Custom Object file.
This can cause large metadata deployment footprint when deploying from version control system with CI Jobs.
For most enterprises, the count of Salesforce metadata will be more than 10,000 members and it can always end up in governor limit issues at the time of deployments.
More details can be found here: https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_metadata.htm
- Maintenance of Package XML: Preparing Package XML file dynamically to list only the members of particular release in the branch is cumbersome.
- Maintenance of the Build Scripts
Benefits of AutoRABIT Salesforce Continuous Integration
- Delta-Based Continuous Integration: AutoRABIT can deploy child metadata components, which are only “modified” in the release and not in the entire Object Definitions.
This can minimize the deployment footprint significantly and make the deployments lean.
- Flexible CI Job Configuration: With AutoRABIT, you can have CI Jobs that can perform the following:
- Deployments Salesforce Org–to–Org from a start date
- Deployments from VCS (GIT or SVN or TFS or Perforce) to Salesforce sandbox
- Deploy the entire branch into Salesforce sandbox
- Deploy from a particular revision from VCS into sandbox
- Deploy a particular revision into sandbox
- Deploy a particular BR/user story directly from Version Control System
- Deployment support for Unmanaged, Managed and Unpackaged Mode in Salesforce.
AutoRABIT Unique CI Capabilities for Salesforce
- Validate Only: Development team can constantly validate deployment of their changes against their release environments so that any possible dependency issues in migration are detected early, reducing the time taken for deployments in SIT/UAT/Pre-Production environments due to dependency issues.
- Automated Apex Test Execution and Code Coverage Reports
- Smart Test Execution: AutoRABIT has the capability to retrieve tests that are committed to VCS in a particular release, run the test classes and give code coverage for the release, providing early warning of lesser code coverage.
- Integrated Data Loading Step: With the integrated Data Loader in AutoRABIT, you can set up Data Loader jobs and add them to your CI Job, so that the entire environment with metadata and data can be set up in one attempt.
- Static Code Analysis: AutoRABIT has static code analysis component integrated into it that can review the Apex Code against the best practices and provide violation reports, along with priorities.
Accelerate Your Continuous Integration (CI) Infrastructure
Recently, I participated in an online panel discussion on the subject of CI Acceleration, as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and DevOps.
You can watch a recording of the panel discussion here
#C9D9, is a community initiative by Electric Cloud, which powers many Fortune clients’ Continuous Delivery to businesses, by automating their build, test and deployment processes, essentially the same space we are in, the difference being that AutoRABIT focuses on the Salesforce.com technologies. There were some interesting insights from the panel discussion that I wanted to share, especially from a Salesforce.com ecosystem perspective that I am involved with.
Defining Continuous Integration?
When you talk of Continuous Integration, a lot of discussions start off with Martin Fowler’s popular post. Several panelists talked about optimizing their infrastructure and how they are burning large budgets for running builds and automated tests. If you consider examples of CI at any social networking companies (Facebook, Twitter, etc.), they are aiming for Continuous Deployment or Continuous Delivery and not just merely Continuous Integration (CI), since a few mistakes are fine. It justifies the time-to-market acceleration and instant feedback from their users is critical. The testament to this is many issues/bugs that surface for new features in sites such as Facebook, Tumbler, SnapChat, etc.
I wanted to give the perspective of a cloud-based technologist, specifically Salesforce.com. In the ecosystem that we work, clients are satisfied with automation of basic development tasks and rudimentary tooling, which is a Herculean process for a relatively new technology. For most of my clients, CI is a journey they are starting and version control enablement is the first step. In a typical team, they have around 15-20 members, though there are larger teams, but I would focus on the average customer (a typical Salesforce.com implementation).
Builds: Tips and Tricks
Most of our client code base is not huge, and the major challenge is release management, accelerating the release cycles and reacting faster to the business needs. This is critical for a business-centric and a revenue-generating software like Salesforce.com.
In this Salsesforce.com ecosystem, a developer would typically spend about 30% of his time managing his/her code. There is a lot of impedance, since the environment is in a multi-tenant cloud and the related restrictions, called governor limits, prohibits one organization (tenant) or one team from monopolizing the shared infrastructure. The typical limits/restrictions are SOQL queries, heap size, data transfer, and session time-out – essentially anything that burdens the infrastructure.
There are workarounds, but most of them are expensive and need extensive tooling and superior DevOps skills, which are rare to find. Typically, most of the Salesforce.com implementations aim for starting a mainline code, a version control, deployment automation, a branching strategy and then later (mostly Phase-II) build automation, test automation (Regression), code coverage and deployment automation.
Testing
Everyone understands the importance of testing and the need to get budgets. But, the effort to showcase the benefits and ROI stops them from securing the budgets. Managers should understand and make the case for testing resources and budgets. The key is data; once managers start collecting data and take the report at the ‘appropriate’ time, it’s a no-brainer most of the time. (You can add/extrapolate standard ROI templates available online)
For Salesforce.com implementations that are more evolved, we suggest categorizing the test cases as ‘gold’, ‘silver’ and ‘bronze’ and using voting for each test case. So, when a test case comes in, the admin knows which ones to use as default, the frequency, the environments, and the test cases that need to be used. In addition, breaking down test cases and having a test plan helps optimize resources. Ultimately, it’s about ‘weight’ in terms of your infrastructure and speed.
From a build management process, one of the key elements is to have a build management strategy. At any given point of time, it’s a process of an evolving document, and so it is with testing, too. The leader or the manager should have a test planning strategy in terms of his budgets, infrastructure usage, and the kind of new processes and new tools that are acquired. He/she needs to understand that every new process takes two or three extra months.
Last, but not the least, test analytics have come a long way and it’s one of the areas that analytics are most underutilized in. Let the algorithms predict which test cases to use, which ones to build, on which module, etc., and be able to run the appropriate test cases. Analytics are becoming mature and dependable. Spend some time and create a project around this; it has great potential, but not every company is leveraging it.
About AutoRABIT
AutoRABIT is an end-to-end Release Management and Continuous Delivery suite, specifically designed for Salesforce applications. AutoRABIT helps Salesforce developers, Admins and Analysts with out-of-box features and automation processes. This helps organizations in achieving Salesforce Continuous Delivery. It enables, Automated Metadata Deployment and Version Control support. This includes Advanced Dataloading and Sandbox Management, end-to-end Release-Management, Defect tracking, and Test Automation for public and private clouds, but is not limited to all these.
With our unique approaches for deployment and automation, AutoRABIT can help release managers migrate both metadata and data seamlessly across environments with the click of a button.
With AutoRABIT, you will achieve higher release velocity (days instead of weeks/months) and rapidly improved time-to-market schedules.
Imagine
Monday morning.
Your ALM Tool indicates that a new User-Story has to be implemented, you are assigned a new task:
“New Custom Fields need to be added to existing custom Objects, some Profile changes need to be applied and Apex classes have to be modified.”
The Sandbox you work in is not your own. Other members of your international team, working in different time zones, need to use it as well. But that does not worry you.
No one on your team can even remember the last time anyone has overwritten someone else’s code. The Version Control System (VCS) together with timestamps and User ID records prohibit that from happening.
This is guaranteed by your cloud hosted Salesforce Release Management Automation Suite which makes logical connections between SFDC – the user of the Salesforce Release Management Automation Suite – as well as all Version Control commits.
You log into your Sandbox and start working on your task. Once done, you save your changes, update your User Story – and, log out.
You do not prepare change sets. Nor will you be updating elaborate excel sheets, you definitely don’t move anything between Orgs manually, and you definitely won’t be caught writing scripts for functional test cases either.
Your work is done for the day. Go have a few drinks with your friends.
The next day.
Your inbox has a new email stating that your changes have been moved through your SIT and QA/UAT, instance without a problem. Currently, they are already being used by many happy end users in production:
Metadata Migration (120 types) – Successful
Static Code Analysis – Successful
Code Coverage – Successful
Full Permission Set Migration – Successful
Full Profiles Migration – Successful
Functional Tests – Successful
Child/Parent Relationship Migration – Successful
Data Migration – Successful
ALM User Story Update – Successful
How did that happen?
While you were asleep AutoRABIT which is your end to end Release Management Automaton Suite ran a comparison between your Sandbox and VC. Triggered by your User Story Update it fetched all your latest changes and did a commit to your SIT branch.
Once complete, a predefined Salesforce Continuous Delivery (CD) process executed the deployment from VCS (SIT Branch) into the Staging and Integration Instance (SIT). It checked on your Code Coverage, emailed all concerned parties about its success and generated a detailed report.
The success triggered the next CD process, by first committing the changes to the QA/UAT Branch in Version Control and then promoting the updated metadata into the QA/UAT Instance. There the Static Code Analysis of Apex classes has been performed. In addition it ran all Functional Test Scripts, emailed all concerned parties about its success and generated a detailed report.
After successfully completing these tasks AutoRABIT – your end to end Salesforce Release Management Automation Suite, once again committed the changes, this time to the Production Branch. Then the metadata was pushed into Production, emails went out to all concerned parties about its success, a detailed report was generated, and the ALM User Story updated.
If this sounds too good to be true I invite you, no dare you to contact us. info@autorabit.com. You will be surprised…
AutoRABIT Partners with Perforce Helix to Improve Salesforce.com Deployments
AutoRABIT partners with Perforce Helix to Improve Salesforcedotcom Deployments.
Salesforce Continuous Integration with Perforce Helix
With Perforce Helix integration , AutoRABIT provides seamless continuous integration for Salesforce customers using Perforce as their version control system .
With AutoRABIT , Salesforce.com customers with Perforce as their version control system can perform the following :
- Check-in the changes from Salesforce Org directly to Perforce Helix with AutoRABIT from browser.
- Create Salesforce CI Jobs to deploy changes from a Perforce Helix Stream into Salesforce Environments.
- Select a particular changelist in Perforce Helix on-demand , perform Org level comparison and deploy the changelist into Salesforce environment .
Here are step-by-step instructions on AutoRABIT – Perforce Helix integration to seamlessly perform CI for Salesforce applications.
Creating a CI Job in AutoRABIT Using Perforce
You can create a continuous integration job in AutoRABIT, with Perforce as version control.
Registering a Repository
- Click Version Control in the menu bar; in the succeeding screen, click Register Repository.
- The following screen is displayed:
- In Version Control System, select Perforce.
- Give a Display Name.
- In P4PORT, supply the name of the root URL.
- In Depot, enter the name of your existing depot.
- For Authentication, give your User Name and Password of your Perforce Helix account.
As the Perforce Helix Depo is registered , you can now create new or load existing streams from Depo into AutoRABIT.
Creating a Project
- Give the required project details (see screenshot below).
Version Control Details of Build Settings
- In Version Control Details, select Perforce and fill in the details of:
- P4Port
- Depot
- Stream Name
- Start Changelist number
You can also provide other details like the destination Salesforce environment , code coverage and static analysis and scheduling for the CI job.
CI Job Results
As the job is run you can find the job results in “Home” section of AutoRABIT for the CI Job.
The results will contain the following:
- Real time status of Packaging , deployment and Test execution.
- List of Salesforce metadata metadata members Packaged and deployed in the job run.
- Lines of Code modified for various Salesforce metadata members .
- Code Coverage.
- Static Analysis results for the Apex Code.
- Functional Test results [ if run ]
Auto-Commit to Version Control
Auto-commit the changes from your Salesforce Org to Perforce Helix.
EZ-commits using AutoRABIT
Using the EZ-commits feature in AutoRABIT, developers can commit the changes directly from their browser to Perforce Depo without any IDEs, plug-ins or clients. This ability will speed adoption of version control for Salesforce teams.
In the following screenshot, Perforce Helix Stream and Salesforce Sandbox are compared to identify the set of changes done in the Salesforce environment and not yet committed to Perforce.
Developers can select some or all of the changes, optionally attach a user story context to the changes and make a commit to send the changes to the version control system.
AutoRABIT has the best Continuous Integration for Perforce Helix and adds more value to Salesforce.com customers using Perforce as their version control system for automating their packaging , deployment and testing of Salesforce Applications.