2CLIX knows that your security and privacy are important and cares deeply about them.
This document aims to describe and provide information about the automated deployment process using Azure DevOps, as well as the controls and security measures involved in this process.
DevOps
The DevOps development culture aims to streamline development and operations by bringing control and automation mechanisms into the delivery pipeline, making both stages faster and more controlled. The Azure DevOps platform is very robust and extensive. In addition to integrations with Microsoft services and the ability to sign in using Azure Active Directory, it also includes dozens of control and automation services. Most importantly, through its integration with Microsoft services, it is possible to use the Azure platform to create integrations between the Visual Studio and Microsoft SQL Server development environments and the company’s operational controls.
2Clix DevOps
The 2Clix DevOps implementation is based on work item management, in which the tasks to be carried out during a development cycle are defined and assigned to the development team. These same work items are tracked by the testing team, which is responsible for quality control of what is being developed in the cycle.
When developers start working on a task, they associate it with their environment in Visual Studio and, once completed, they push the changes to the cloud repository managed by Azure DevOps, which then starts an automated deployment routine to the test environments.
Currently, 2Clix DevOps has three deployment routines: deployment to the Development environment, a test-focused environment for improvements and new features, which has its own dedicated and anonymized database completely separate from the production network. The second routine is deployment to the Staging (Homologation) environment, intended for testing critical fixes or for pre-release testing. This database is created by a weekly mirroring and full anonymization routine of the production database and also runs in a separate instance. These two routines are fully automated, so that whenever a new check-in is made to any of these environments, a new deployment is automatically performed.
Finally, there is the third and last process, which is deployment to Production. This process is executed via Azure DevOps pipelines; however, it is not automated, since every production deployment must first be approved by the Quality team. In this process, the pipeline is scheduled for a non-working day outside of business hours.
Access to the servers responsible for these environments is granted only to the automated agents of Azure DevOps; therefore, no developer has direct access to them. Access to the servers is restricted to the Infrastructure team for carrying out maintenance required to ensure server security and integrity.
