By bringing application development and operations management to the same platform, SF DevOps is the new normal in enterprise application development. Previously, in the conventional development process, testing used to be very confusing and time-taking as it usually came as an afterthought. Testing always was something relegated to one among the largely forgotten parts of the application phase-gate cycle. Now, in the SF DevOps era, this paradigm had largely changed by helping the teams to take new ideas to the market much quicker. This is achieved by efficiently integrating ongoing testing through the DevOps development process.
In many organizations, it is evident that with a limited number of resources and an ever-increasing need to cut short the release cycles of products and upgrades, testing must be integrated through CI/CD (Continuous Integration/Continuous Development) tools they use. On talking to many development teams, it is found that most of these teams possess skills and experience to do this. It is all about initiating a dialogue to explore the possibility and equipping them with the resources to align it in the success track. This is where SF DevOps CI/CD tools come into play.
Based on the talks with such development teams, here we will discuss a few best practices successful teams follow to be proactive testers. By initiating this productive conversation at the earliest and using SF DevOps tools, your team can also work together to integrate the tasks better and release applications much faster and more reliably. This new approach is not about doing more tests frequently, but it is about creating meaningful tests which will protect the crucial aspects of your business application development.
The key questions
Here are some key questions SF DevOps and testing teams need to discuss during their project planning discussions:
- Do we test all features and functionality at every stage of development or need to wait for it to mature to a higher level as a staging or UAT environment?
- Is there a need to perform regression testing on each functionality or how often do the regression testing to be performed?
- Whether to test the features at the end of each release cycles?
- How much time to be spent on weekly testing data?
- What could be the amount of time taken for a line of code to go from the Development phase to Production?
Each enterprise development team may have their unique style of development and different testing goals. So, as we discussed above, it is important to start with an internal dialogue to discuss the development objectives and desired outcomes to create an appropriate testing strategy, which will support these goals.
SF DevOps challenges
When applied to the Salesforce development process, SF DevOps possesses many challenges which you need to address effectively to sail towards success. DevOps is not like a standard Java-based (Maven-Jenkins type) development environment. It is more about managing the object configurations, which keeps on changing and finally releasing those. It is less about code writing as in case of a conventional Java development.
The major DevOps development challenges are as below:
Low level of test confidence
In the standard DevOps development environments, there could be untested new deployments for each request between different testing environments. With this, the testing may suffer while the environments differ, which may result in some production issues or product defects. This loss of confidence in testing may lead to a need for rework and time wastage.
Environments not in sync
There is a possibility of the environments getting out of sync frequently. Refreshment of the same may take time, and deployments can have further errors.
Challenges in deployment
Deployments, when done manually, can have various bottlenecks during the test faces and project deployments. If the developers update the environments directly from their end, it may sometimes lead to missed steps in the deployment process. Further releases which are built on old production refresh may also require add-on testing time which ends up in deployment delays.
Maintenance-related issues
With many manual steps and higher outrage windows, it could be painful to go live efficiently on time. Managing different development environments in the same projects and simultaneously managing multiple project streams may also pose certain hurdles. Say, for example, R1 Major Release, R2 Major Rel, Prod Hot Fix, Features 1 and 2 Releases etc. with different degrees of Prod Envs.
SF DevOps solutions to tackle the challenges
Considering the above challenges, we can find the following solutions offered by SF DevOps, which will help both the development and QA teams to handle those effectively.
- Change history visible to all development and operations team members.
- Provision to alert the developers on finding a code conflict.
- Running the test classes in sandboxes so that the issues can be easily discovered at an earliest possible stage.
- Rolling back to a previous stage any point in time
- Rollback any specific change in isolation
- Enabling daily or weekly deployments
- Enabling the Release Management Team to manage the deployments
- Making sure that the workflow is not much complicated for the Delivery Teams
- Enabling Delivery Team leads to initiate the releases.
- Delivery Team Leads can create releases which can be used by the Release Management Teams for effective deployments.
SF DevOps Milestones for success
Milestone #1: Establishing a proper source code control and brining proper governance to the code review for more transparency.
Milestone #2: Empowering the developers by providing real-time feedback on deployment validation if there are any errors.
Milestone #3: Ensuring an ongoing deployment lifecycle which is automated with immediate validations when codes are merged.
Scheduled, triggered, and on-demand deployments need to be ensured to keep all different environments within and outside the development projects well in sync. You may also add code review automation tools and Selenium scripts for regression testing to the SF DevOps pipeline to ensure more resilience and conformity.
Conclusion:
Application development with SF DevOps possesses is more about effectively managing the configurations than about coding of applications. To a greater extent, there is an Apex environment too which should not be ignored.
