Introduction: Why does 1C need CI/CD?
If you work with the 1C platform, then you have probably encountered a situation where after the next update something breaks in the combat base, and you can't roll back the changes quickly. Or when a development team is working on a single configuration, and one programmer's code overwrites another's changes. Sound familiar?
CI/CD (Continuous Integration / Continuous Delivery) is a set of practices that automate the process of developing, testing and deploying software. Although these approaches have long been the standard in web development, they are only gaining popularity in the 1C world. And this is understandable: the 1C ecosystem is specific, works with its own configuration formats and requires a special approach to versioning.
In this article, we will analyze how to build a simple but effective CI/CD pipeline for 1C, which automates routine operations and makes your work more predictable and secure.
What is CI/CD in simple words?
Continuous Integration means that all code changes are regularly merged into a common development branch, and the system automatically checks whether these changes have broken something important. Imagine that every time you save changes to the configuration, the robot automatically checks the syntax, runs tests, and tells you if something went wrong.
Continuous Delivery is the next step when your code is automatically prepared for deployment on a test or production server. Instead of manually exporting the configuration, copying files, and updating databases, this entire process takes place automatically at the touch of a button or even without your participation.
Features of 1C that need to be considered
The 1C platform has a number of features that make the implementation of CI/CD a little more difficult than in conventional web development. First, 1C configurations are stored in binary files (.cf), which are difficult to version with conventional Git tools. Secondly, working with 1C requires an installed platform, which complicates the setup of automated environments. Thirdly, 1C has its own specifics with object locks, monopoly mode and database update features.
However, all these difficulties are solvable. There is a format for uploading configurations in XML, which is great for Git. The 1C platform can be run in thin client mode or without a GUI at all, which allows it to be used in automated scenarios. And to solve specific problems, 1C has created several open-source tools, which we will talk about later.
Automation tools
To build a CI/CD pipeline for 1C, you will need several tools. Let's start with the version control system — here the choice is obvious: Git. This is an industry standard, and it is ideal for working with 1C if you correctly configure the configuration storage format.
The key tool is OneScript, a 1C language interpreter that works outside the 1C platform. It allows you to write scripts in a familiar language and perform various operations with configurations. Useful utilities such as vanessa-automation for automated testing and gitsync for synchronization with Git have been created on the basis of OneScript.
For the CI/CD server, you can use popular solutions: GitLab CI, Jenkins, GitHub Actions, or even TeamCity. The choice depends on your preferences and the company's infrastructure. For beginners, I recommend GitLab CI or GitHub Actions, as they provide free hosting solutions and have a simple setup through YAML files.
You will also need a tool to work with configurations from the command line. Here you can use the standard features of the 1C platform (configurator in /C mode) or specialized utilities such as v8unpack to unpack configurations in XML.
Setting up the basic structure of the project
The first step to automation is the correct organization of the project. Instead of storing .cf binary files in Git, you need to upload the configuration in XML format. To do this, create a src folder in the root of your project, where the source code of the configuration will be uploaded as separate XML files for each metadata object.
The structure of a typical 1C project in Git may look like this: the root folder contains the src directory with the uploaded configuration, the tests folder with automatic tests, the scripts folder with service scripts for building and deploying, as well as configuration files for the CI/CD system, for example, .gitlab-ci.yml or .github/workflows/main.yml.
It is important to add files that do not need to be versioned to .gitignore: 1C temporary files with the .tmp extension, .1CV8 lock files, folders with cache and logs. Also, do not store the infobases themselves in the repository — only the source code of the configurations.
Creating the first pipeline
Let's create a simple CI/CD pipeline that will perform basic checks on each commit. We will use GitLab CI as an example, but the logic applies to other systems as well.
Create a .gitlab-ci.yml file in the project root and define several steps: syntax check, configuration build, test run, and deployment. In the first stage, the pipeline checks the configuration syntax — this is a quick operation that allows you to catch obvious errors like unclosed brackets or incorrect variable names.
To check the syntax, you can use the 1C configurator in command line mode. Create a script that loads the configuration from XML files into an empty infobase and runs a configuration check. If the configurator finds errors, the script must end with a non-zero return code, and the pipeline will stop.
The second stage is the configuration assembly. Here, a full-fledged cf-file is collected from XML files, which can be used for deployment. This file is saved as a pipeline artifact and can be used in the next steps or downloaded manually.
The third stage is the launch of automatic tests. If you use a framework for testing such as Vanessa-Automation or ADD, all written tests are run here. Tests are performed on a temporary infobase, which is created specifically for this stage and is deleted after completion.
The final stage is deployment. This stage can only be run for certain branches (for example, master or release) and updates the test or production database. It is important to implement this stage so that in case of problems it is possible to quickly roll back to the previous version.
Test automation
One of the main values of CI/CD is automated testing. There are several frameworks for 1C that allow you to write automated tests. The most popular is Vanessa-Automation, which supports the BDD-style of writing tests (Behavior Driven Development).
BDD tests are written in natural language in the Gherkin format: Given, When, Then. For example, a test might look like this: given that I opened the document creation form, when I filled in the "Counterparty" field with the value "Horns and Hooves LLC", and I clicked the "Record" button, then the document should be recorded without errors. These scenarios are understandable not only to programmers, but also to analysts or testers.
Each such scenario is associated with the implementation in the embedded 1C language, which performs actions and checks the results. It is important to cover critical business processes with tests: posting documents, calculating registers, and generating reports. Even a small set of such tests significantly increases the stability of development.
Branching and release strategies
For CI/CD to work effectively, you need the right branching strategy in Git. For teams working with 1C, a simplified Git Flow is well suited: the main master (or main) branch contains stable code ready for deployment in production, the develop branch is used to integrate new features, and separate feature branches are created for each task.
When a developer starts working on a new task, he creates a branch from develop with a clear name like feature/add-inventory-report. After the work is completed, a merge request (or pull request) is created, which automatically starts the CI pipeline. If all checks are successful and the code review is completed, the branch is merged into develop.
To create a release from develop, a release branch is created, on which final checks and bug fixes are performed. After successful testing, the release branch is merged into the master, tagged with the version number, and automatically deployed to the production system.
Deploying and rolling back changes
The process of deploying the 1C configuration has its nuances. You can't just take and replace files — you need to correctly update the infobase, process changes in the data structure, and check compatibility. To automate this process, scripts are used that update the database via a COM connection or in /C mode.
It is critically important to back up the database before updating. In the deployment script, the first step should be to create a backup that is saved with a time stamp and version number. If something goes wrong after the update, this backup will allow you to quickly roll back to the previous version.
After updating the configuration, it is recommended to run smoke tests — a small set of checks that quickly check the performance of the main functions of the system. For example, you can try to open the main form, create a simple document, and perform a typical calculation. If the smoke tests fail, the deployment should be considered unsuccessful and an automatic rollback should be performed.
Monitoring and notifications
An important part of any CI/CD pipeline is the notification system. Developers should immediately know if their commit broke the build or failed the tests. Most CI/CD systems integrate with messengers such as Telegram, Slack, or corporate systems.
Configure notifications so that they are informative, but not spam. For example, you can send messages only when tests fail or when a successful deployment to production occurs. The notification should contain basic information: which branch, who is the author of the commit, which stage of the pipeline has failed, and a link to detailed logs.
It is also useful to collect metrics: how long it takes to run the pipeline, how often tests fail, how much time passes from commit to deployment to production. This data helps you find bottlenecks and improve development processes.
Practical tips for beginners
Start small. Don't try to build the perfect CI/CD with all possible checks right away. Start with basic syntax validation and automatic configuration assembly. When it works consistently, add a few simple tests. Then automate the deployment to the test server. And only when the entire chain is worked out, proceed to automatic deployment on production.
Document processes. Create a README file in the project root, where you describe how your CI/CD works, what commands you need to execute for local development, and how to create releases. This is especially important if there are several developers in the team or if the project is transferred to another team.
Do not ignore failed tests. If the pipeline shows red, this should be the number one priority. The "red" pipeline normalizes the situation when the tests do not pass, and over time the team stops paying attention to it. The rule is simple: if the test fails, either you need to fix the code or fix the test, but the pipeline should turn green again.
Set aside time to train the team. The implementation of CI/CD changes the development processes, and not all developers may be ready for this. Hold a few meetings where you explain why it is necessary, how it works, and show examples. It is better to spend a few hours on training than to fight resistance to change for months.
Typical problems and their solutions
One of the most common problems is slow pipeline operation. Complete assembly and testing of the 1C configuration can take tens of minutes. To speed up the process, use caching: save the collected configurations and databases between pipeline runs. Divide the tests into quick smoke tests that are always performed and a full set of tests that are run only for important branches.
Another problem is conflicts when merging XML configuration files. Git does not always correctly resolve conflicts in XML, especially if two developers have changed the same metadata object. The solution is to use specialized tools for merging 1C configurations, such as gitsync or EDT (1C:Enterprise Development Tools), which understand the metadata structure.
Sometimes there are problems with 1C licenses on the CI server. Automated processes require licenses that allow running without a GUI. Discuss with your licensing manager what options are available for your configuration. As an alternative, you can use demo versions of the platform for testing, although this has its limitations.
Conclusion
Building CI/CD for 1C is not a quick process, but the time investment pays off many times over. Automation eliminates routine, reduces errors, and makes the development process more predictable and professional. Your team will be able to release updates more often and with greater confidence, and the quality of the code will inevitably increase.
Start simple: set up Git to store configurations, add basic syntax validation to CI, and write your first automated tests. Gradually expand the functionality of the pipeline, adding new checks and automating more processes. And remember: the main goal of CI/CD is not to use complex technologies, but to improve the quality of development and the life of developers.
Want to know more?
You can study modern approaches to development, process automation, CI/CD and many other technologies on the educational platform Code. We create practical courses for developers of any level, from beginners to experienced professionals.
And we also have a cool Telegram channel with a friendly community where you can discuss technical issues, share experiences and find like-minded people. Join us! 🚀