DevOps inside out – how does it work?

DevOps — why does it pay off?

We are not only practitioners, but also enthusiasts of the DevOps approach mentioned above. However, when we recommend it to the clients, we often must start from the basics, that is from explaining what this method is precisely about. What does it exactly mean that we combine development and support withing a single team, and work parallelly in both areas?

Before we explore the DevOps ins and outs, let me explain what it is used for and to what end. In my opinion, this aspect is no less significant than the technological background, and the answer is much more apparent than it might seem. DevOps increases the effectiveness of the team, and it helps to solve the eternal problem that we face in IT projects: the dependence of the production environment on the new releases. When the process is operating smoothly, we release a new version to production because we do not wait for the incidents to be fixed until the work on new functionalities are over. If we get any reports, we react to them and fix them on an ongoing basis.

It is possible thanks to the use of code repository and Continuous Integration. It allows managing the provision of further functionalities so as to minimize manual work, and consequently the risk of mistakes and differences between environments. Everyone who has any experience in working on an IT project knows what this job often looks like: various environments, implementing changes that are not visible in another environment because something is lost along the way.

When a project is carried out according to Continuous Integration approach, we do not have to wait until a developer pushes something on a server. That is what tools are for (for example, Jenkins server). Automation gives us operation continuity and full control over the project.

It sounds quite technical. So, in that case, are the benefits of implementing DevOps felt only by developers and admins? No, and this is something we point out during conversations with clients: the benefits are visible for the business as well. When we present to a customer assumptions of working in the DevOps model, the message is clear: in IT, we are flexible, we do not create artificial barriers nor operating rules. There are no dos and don’ts such as “it has to wait; we cannot do this because we are busy with something else.” DevOps removes roadblocks, ensures smooth operation, and rapid response. It increases transparency — the client knows what the team is currently working on. The advantages of DevOps implementation are an extensive subject, and I will return to the issue in the following articles.

DevOps in practice step by step

What does DevOps mean in practice? How does the DevOps team work at Craftware? I will discuss the crucial technical aspects of working according to this approach.

• Version control

Theoretically, it is something that is pretty obvious in projects, but not so obvious in Salesforce. At Craftware, we keep to the principle: if there is no repository, there is no control. Furthermore, there is no DevOps without a repository. Working with a repository is the foundation of this approach.

An essential element of version control is the rule of at least one acceptance. What does it mean? When there is more than just one developer in a project, we recommend mutual verification of changes in the code before storing it into the repository. The more extensive the acceptance system is, the better.

We also recommend including an additional acceptance stage: launching unit tests before placing the code in the repository, at least at the stage of the integration environment and the subsequent ones.

• GIT Flow

It is our recommended method of working with the code repository, meaning the way the code has to go through before it ends up in the production system.

The diagram below explains it. The Master branch represents the production system, the Develop branch — the code of a new release. As you can see, after subsequent changes on the Develop level, the code does not go directly to production but needs to go through the Release level first.

Image – GIT Flow

• Sandbox hierarchy and Continuous Integration

It is nothing but the sequence of code testing stages in line with Continuous Integration standards. Sandbox in Salesforce means a test environment. It is worth mentioning that creating these environments in Salesforce is much easier than in other technologies. A copy of production environment can be clicked out in a few minutes.

Our suggested test scheme for more complicated Salesforce instances is presented in the figure below.

Image – Sandbox hierarchy

Clearly, in the case of several parallel projects, each has its own test environment. The one called Integration is the first in which we can detect errors, precisely negative impact of a mistake in one of the projects on the rest of them.

The integration environment is a working one; it is not recommended for official tests because there can be many changes in projects, even during one day. A version is released to the next stage of testing only after a stabilization in this working environment. Often, the business is also invited to the latter stage.

I draw your attention to the Hotfix environment. What is its role? Preparation of a new release may take months. There is no guarantee that during this time, there will be no production errors. Thanks to the Hotfix environment, malfunctions can be effectively and safely repaired without waiting for a new functionality. It contains the production code (but no releases), so you can test the fixed version there without risk.

We emphasize the meaning of Continuous Integration on each stage of tests not without a reason: the more complicated project, the more prominent role CI plays. We are talking about many code transitions between environments, numerous changes in each of them, because there can be many of them during a day. In such a situation, process automation is an important facilitation.

• Release management goals — an aware approach to releases

In the DevOps approach, it is a crucial aspect. A new release in an IT project is not something that happens every day, and this is something you need to remember. No matter if it will happen in three weeks or three months — waiting for it cannot stop improvements in the production environment. I keep telling this (and, probably, not the last time), but it is DevOps nature: development and support do not exclude each other; they can be — and should be! — carried out at the same time.

Of course, you need to be sure that anything that got to production, was adequately tested and works fine. Proper configuration of the Continuous Integration process eliminates most of the issues related to it. And the most often issue developers struggle with is that there is an old code in the production environment.

Such a common-sense approach affects the work of the team — it allows managing assets effectively. However, preparing new functionalities is not equally time-consuming; a particular release requires more work and the other one less. So it is possible to plan work well in advance within the context of leaves or holidays.

• Automated tests

Automated tests may seem expensive and unprofitable. And indeed, at the beginning, there are no significant advantages from conducting them. But the more extended system is, the more useful such tests are.

For example, in the system, there are already a few basic paths followed by a user. Writing an automated test will probably take a lot of time, and if the system is not developed, time spent on test preparation may not be returned. But if new functionalities are regularly added to the system, time invested in writing those tests pays off many times.

The significance of automated tests is visible especially in the context of regression testing. We often assume that if we change only a certain fragment of the code, it will not affect errors in other parts of the software. But the practice proves that we are not capable of predicting that. Thanks to launching automated tests, we can verify a wider range of code saving manual testers work. And it has an impact on decreasing time to market.

Summary

Implementing DevOps in Salesforce projects does not have to be complicated. Sometimes the hardest thing is to start, but it just requires a change of attitude to carrying out a project. Our clients who follow our recommendations, more and more often convince themselves to this approach seeing , also the business ones.