Update repostructure.md
translate repostructure to kor
This commit is contained in:
Родитель
1f298d2429
Коммит
b741658abd
|
@ -1,24 +1,24 @@
|
||||||
---
|
---
|
||||||
title: "Policies: Repository Structure"
|
title: "정책: 저장소 구조"
|
||||||
permalink: policies_repostructure.html
|
permalink: policies_repostructure.html
|
||||||
folder: policies
|
folder: policies
|
||||||
sidebar: general_sidebar
|
sidebar: general_sidebar
|
||||||
---
|
---
|
||||||
|
|
||||||
To help make our repos more consistent and easier to approach from our team as well as the community we should have a consistent structure. That structure should avoid putting a lot of stuff in the root of the repo to make it appear neater and allow folks visiting the repo to quickly see the root README.md without needing to scroll. The directory structure should look like:
|
팀뿐만 아니라 커뮤니티에서도 저장소를 보다 일관되고 쉽게 접근할 수 있도록 하려면 일관된 구조를 갖춰야 합니다. 이러한 구조는 저장소 루트에 많은 내용을 배치하지 않도록 해야 하며 저장소를 방문하는 사람들이 스크롤하지 않고도 루트 README.md을 빠르게 볼 수 있도록 해야 합니다. 디렉터리 구조는 다음과 같습니다:
|
||||||
|
|
||||||
- `common` - Will contain source code or projects that are not shipping artifacts but are shared and used by our sdk libraries. Things like common test projects or shared test or source code.
|
- `common` - 만들어 진 것을 제공하지 않지만 SDK 라이브러리에서 공유 및 사용하는 소스 코드 또는 프로젝트를 포함합니다. 일반적인 테스트 프로젝트나 공유 테스트 또는 소스 코드와 같은 것입니다.
|
||||||
- `doc` - Contains documentation, usually in markdown files, for anything in the repo. It should also contain a README.md that states the purposes of all the folders under `doc`. ([Example](https://github.com/Azure/azure-sdk-for-python/blob/main/doc/README.md))
|
- `doc` - 저장소의 모든 항목에 대한 설명서(일반적으로 Markdown 파일)를 포함합니다. 또한 `doc` 아래에 있는 모든 폴더의 용도를 설명하는 README.md을 포함해야 합니다. ([예제](https://github.com/Azure/azure-sdk-for-python/blob/main/doc/README.md))
|
||||||
- `doc\dev` - Contains the set of documentation needed for developers that are contributing to the repository.
|
- `doc\dev` - 저장소에 기여하는 개발자에게 필요한 설명서 모음을 포함합니다.
|
||||||
- `eng` - Used to contain things needed by the engineering system to build, test, or perform other related tasks. It will usually contain configure files, build definitions, scripts and other tools (generally not checked in binaries).
|
- `eng` - 엔지니어링 시스템이 다른 관련 작업을 구축, 테스트 또는 수행하는 데 필요한 것들을 포함하는 데 사용됩니다. 일반적으로 구성 파일, 빌드 정의, 스크립트 및 기타 도구(일반적으로 이진에서는 확인되지 않음)가 포함됩니다.
|
||||||
- `sdk` - Primary directory which will contain our sdk library source code. See below for more details on its layout.
|
- `sdk` - SDK 라이브러리 소스 코드를 포함할 기본 디렉터리입니다. 레이아웃에 대한 자세한 내용은 아래를 참조하십시오.
|
||||||
|
|
||||||
|
|
||||||
To accomplish that every azure-sdk language repo will put a README.md and a `sdk` folder in the root that will contain a folder for each service which will then contain a folder for each package associated with the service. It will be `sdk`, singular as opposed to plural, because we want developers to realize we only have one azure sdk and not many.
|
이를 위해 모든 Azure-sdk 언어 저장소가 루트에 README.md 및 sdk 폴더를 배치하고, 이 폴더에는 서비스와 연결된 각 패키지의 폴더가 포함됩니다. 개발자들이 우리가 azure sdk를 하나 가지고 있고 많지 않다는 것을 깨닫기를 원하기 때문에 여러 개의 sdk가 아닌 하나의 sdk가 될 것입니다.
|
||||||
|
|
||||||
### SDK directory layout
|
### SDK 디렉터리 레이아웃
|
||||||
|
|
||||||
Every azure-sdk language repo will put a README.md and a `sdk` folder in the root that will contain a folder for each service which will then contain a folder for each package associated with the service. It will be `sdk`, singular as opposed to plural, because we want developers to realize we only have one azure sdk and not many.
|
모든 azure 언어 저장소는 루트에 README.md 및 sdk 폴더를 배치합니다. 이 폴더에는 각 서비스에 대한 폴더가 포함되어 서비스와 연결된 각 패키지의 폴더가 포함됩니다. 개발자들이 우리가 azure sdk를 하나 가지고 있고 많지 않다는 것을 깨닫기를 원하기 때문에 여러 개의 sdk가 아닌 하나의 sdk가 될 것입니다.
|
||||||
|
|
||||||
```
|
```
|
||||||
sdk\<service name>\<package name>\README.md
|
sdk\<service name>\<package name>\README.md
|
||||||
|
@ -27,22 +27,23 @@ sdk\<service name>\<package name>\*tests*
|
||||||
sdk\<service name>\<package name>\*samples*
|
sdk\<service name>\<package name>\*samples*
|
||||||
```
|
```
|
||||||
|
|
||||||
- **`<service name>`** - Should be the short name for the azure service. It will be used to group all the various packages for a given service, including the management and data-plane packages, as well as any multi-api (e.g. or different profile versions (e.g AzureStack). Any shared artifacts like release notes or versions should go into this root repo. These names should match across all the different language repos and by default should be what is in the specification folder in the [azure-rest-api-specs](https://github.com/azure/azure-rest-api-specs) repo.
|
- **`<서비스 이름>`** - Azure 서비스의 줄임말이어야 합니다. 관리 및 데이터 플레인 패키지를 비롯한 특정 서비스에 대한 모든 다양한 패키지와 멀티 api(예: 또는 다른 프로파일 버전(예: AzureStack))를 그룹화하는 데 사용됩니다. 릴리스 정보 또는 버전과 같은 모든 공유 산유물은 이 루트 저장소에 저장되어야 합니다. 이러한 이름은 서로 다른 모든 언어 저장소에서 일치해야 하며 기본적으로 [azure-rest-api-specs](https://github.com/azure/azure-rest-api-specs) 저장소의 규격 폴더에 있어야 합니다.
|
||||||
- **`<package name>`** - Should be the name of the shipping package, or an abbreviation that distinguishes the given shipping artifact for the given service. The key is that there is source for only one shipping package in this folder.
|
- **`<패키지 이름>`** - 배송 패키지의 이름 또는 지정된 서비스에 대한 지정된 배송 창작물을 구분하는 약어여야 합니다. 중요한 것은 이 폴더에 하나의 배송 패키지에 대한 소스가 있다는 것입니다.
|
||||||
- If there are multiple packages with the same name but different scope/org/groupid/SxS-version/etc then put them each in their own folder under the service name directory with names that match whatever distinguishes them from each other.
|
- 이름이 같지만 scope/org/groupid/SxS-version 등이 서로 다른 패키지가 여러 개 있는 경우 서로 구분되는 이름과 함께 서비스 이름 디렉터리 아래의 고유한 폴더에 각각 넣습니다.
|
||||||
- If there are long file path issues then you can use an abbreviation of the package name to help avoid issues. For example Java tools require every part of the package/namespace to be a separate folder which can make the paths extra long and thus may need to abbreviate the package name to help alleviate the impact of long file paths on windows.
|
- 파일 경로 문제가 긴 경우 패키지 이름의 약어를 사용하여 문제를 방지할 수 있습니다. 예를 들어 Java 도구는 package/namespace의 모든 부분을 별도의 폴더여야 하므로 경로가 너무 길 수 있으므로 긴 파일 경로가 창에 미치는 영향을 완화하기 위해 패키지 이름을 축약해야 할 수 있습니다.
|
||||||
- If there are other assets that aren't shipping packages, such as shared libraries/source code or tools, they can also go in a folder under the service name directory.
|
- 공유 라이브러리/소스 코드 또는 도구와 같이 패키지를 제공하지 않는 다른 자산이 있는 경우 서비스 이름 디렉토리 아래의 폴더로 이동할 수도 있습니다.
|
||||||
- Every package directory must contain the following:
|
- 모든 패키지 디렉터리는 다음을 포함해야 합니다:
|
||||||
- A README.md in the package root folder that contains documentation for the package
|
- 패키지 루트 폴더에 패키지에 대한 설명서가 들어 있는 README.md입니다.
|
||||||
- A folder which contains the source code for the library contained in the package in whatever format is appropriate for the specific language and tools.
|
- 패키지에 포함된 라이브러리의 소스 코드가 특정 언어 및 도구에 적합한 형식으로 들어 있는 폴더입니다.
|
||||||
- A folder which contains the test code for the library contained in the package in whatever format is appropriate for the specific language and tools.
|
- 패키지에 포함된 라이브러리의 테스트 코드가 특정 언어 및 도구에 적합한 형식으로 들어 있는 폴더입니다.
|
||||||
- A folder which contains sample code for the library contained in the package in whatever format is appropriate for the specific language and tools.
|
- 특정 언어 및 도구에 적합한 형식으로 패키지에 포함된 라이브러리의 샘플 코드가 들어 있는 폴더입니다.
|
||||||
|
|
||||||
#### Special considerations for application frameworks
|
|
||||||
|
|
||||||
The azure-sdk language repositories will sometimes contain modules/libraries/packages which provide integration between popular application frameworks as Azure services. For example Spring Boot, Spring Data, or ASP.NET. In general the modules that provide integration with a specific service should be co-located with the other modules for that service. In very limited circumstances an application framework may contains shared logic used across multiple integrations, or all integrations are in a single module. In those cases the module may be placed in a directory named after the application framework (e.g. ```sdk/spring/```).
|
#### 애플리케이션 프레임워크에 대한 특별한 고려 사항
|
||||||
|
|
||||||
### Examples:
|
Azure-sdk 언어 저장소에는 Azure 서비스로 널리 사용되는 애플리케이션 프레임워크 간의 통합을 제공하는 모듈/라이브러리/패키지가 포함될 수 있습니다. 예를 들어 스프링 부트, 스프링 데이터 또는 ASP.NET가 있습니다. 일반적으로 특정 서비스와의 통합을 제공하는 모듈은 해당 서비스의 다른 모듈과 함께 배치해야 합니다. 매우 제한된 상황에서 애플리케이션 프레임워크는 여러 통합에서 사용되는 공유 논리를 포함하거나 모든 통합이 단일 모듈에 포함될 수 있습니다. 이 경우 모듈은 응용 프로그램 프레임워크의 이름을 딴 디렉토리에 배치될 수 있습니다. (e.g. ```sdk/spring/```).
|
||||||
|
|
||||||
|
### 예제:
|
||||||
|
|
||||||
#### .NET Repo
|
#### .NET Repo
|
||||||
```
|
```
|
||||||
|
@ -90,4 +91,4 @@ sdk\keyvault\keyvault\README.md
|
||||||
sdk\keyvault\keyvault\src
|
sdk\keyvault\keyvault\src
|
||||||
sdk\keyvault\keyvault\test
|
sdk\keyvault\keyvault\test
|
||||||
sdk\keyvault\keyvault\samples
|
sdk\keyvault\keyvault\samples
|
||||||
```
|
```
|
||||||
|
|
Загрузка…
Ссылка в новой задаче