저는 주로 Java EE 개발자입니다. 곧 웹 프로젝트에서 Smalltalk/Seaside를 사용할 가능성을 탐구 해 달라는 요청을 받았습니다. 상상할 수 있듯이, 이것은 많은 흥미로운 질문을 이끌어 냈습니다. 스몰 토크/해변 용 버전 제어?
어떻게 개발자 팀은 스몰 토크/해변과 소프트웨어 버전 및 개정 제어를 구현 않습니다. Subversion이나 Git을 사용할 수 있습니까?내가 아는 바로는 스몰 토크는 각 클래스를 자체 파일로 저장하는 대신 이미지를 사용합니다. 이는 특히 팀 전체에서 소스 코드 개정을 관리하는 능력에 어떤 영향을 줍니까?
당신이 제공 할 수있는 통찰력에 대해 많은 감사드립니다!
설정은 자신의 이미지에서 작동합니다. 작성한 메소드에 대한 모든 변경 사항은 변경 사항 파일에 로컬로 저장됩니다. 이렇게하면 이미지가 손상 될 때 복구 할 수 있습니다. 커밋은 패키지 이름, 시퀀스 번호 및 개발자 이름이있는 monticello 파일을 만들어 수행합니다. 그것의 조상을 압니다. 이 파일은 WebDAV 서버에 저장됩니다. 여기에 Jenkins task에 의해 선택됩니다. 이것은 유닛 및 통합 테스트를 실행하고 새로운 이미지를 생성하므로 개발자는 매일 새로운 이미지로 시작할 수 있습니다. 다음은 monticello를 사용하는 merging에 대한 세부 정보입니다. 제품 구성 (패키지 구조)은 metacello 설명을 포함하는 또 다른 monticello 파일입니다. 또한 Pharo에서 개발하고 Gemstone에 배포 할 수 있습니다. 가끔 클래스 마이그레이션을 추가해야합니다.
비 스몰 토크의 종속성 및 개발, 테스트의 수용과 생산의 차이를, (곧 희망 Coral, 또는 puppet) vagrant, chef-solo를 사용하여 버추얼 이미지, veewee의 생성을 추가합니다. 그들은 물론 git을 사용하여 관리되는 버전입니다. 정적 코드 품질 관리 도구를 사용하는 것 외에도
, Moose을 추가하고 VisualWorks 스몰 토크 현지 개발자에 의존 프로젝트 (humane assessment)
의 동적 시각화를 자신의 컨텍스트를 만드는 (smallLint도 스몰 토크 방언의 차이를 확인) STORE를 관계형 데이터베이스 (예 : PostgreSQL)와 함께 사용하여 로컬 커밋을 저장합니다. 이 코드는 네임 스페이스가있는 패키지 번들로 구성됩니다. 복제 스크립트는 로컬 버전을 중앙 데이터베이스간에 복사하는 데 사용됩니다. 거기에서부터 흐름은 Pharo 설정과 동일합니다. Esug2012에서
[업데이트], 데일 Henrichs은 가능한 여러 방언에 대한 스몰 토크 코드를 관리하기 위해 자식과 github의를 사용할 수 있도록하는 작업을 발표했다. 기본적으로 디렉토리에 smalltalk 메소드를 저장하기위한 파일 구조가 정의되었습니다 (VisualWorks의 경우 Amber, Gemstone, Pharo, Squeak, VisualAge, STIG의 경우 Cypress). 이것은 현재 네이티브 SCM 대신에 방언 간의 코드 교환에 더 중점을두고 있습니다.
VA Smalltalk는 Envy있다.
어느 스몰 토크를 선택 하든지간에 나는 해변가를 정말 좋아할 것이라고 생각합니다.
짧은 대답 : 당신은 (지금은) 힘내거나 서브 버전을 사용할 수 없습니다.
심지어 짧은 대답 : 당신이 그것을 필요가 없습니다 :
대형 대답 : 당신이 기반 파일 시스템에 사용되는 경우 Pharo의 그 자체는 물론 ) : 작성 방법에 대한 스테판의 설명을 참조하십시오,이 처음에는 이상하게 느껴지 겠지만, 일단 작업을 시작하면, 버전 제어 (monticello - 이것은 Git/Subversion의 대체 임)와 복잡한 설치 (metacello)를 만드는 데 필요한 모든 도구가 있다는 것을 깨닫게 될 것입니다. maven과 같은 것을 대신하는 것). 일부 작업 (항상 선택한 플랫폼으로)을 사용하면 자신의 연속 통합 서버 (젠킨스 또는 허드슨 등)를 설정할 수 있으며 곧 다른 환경에서와 마찬가지로 팀을 구성 할 수 있지만 큰 장점이 있습니다. P
Smalltalk에서의 개발은 일반적으로 더 생산적이지만 - 먼저 새로운 도구에 대해 알아야합니다. 패키징을 위해서는 Monticello/Metacello가 필요합니다 (mcz를 사용하여 패키지를 ZIP 파일로 저장하는 것으로 생각하십시오). 확장 및 커밋 할 때마다 자체 버전 번호). Metacello는 Monticello 패키지가 함께 들어있는 정보를 제공하며 Maven의 POM과 유사하지만 XXX라는 클래스가있는 특정 클래스 파일 인 ConfigurationOfXXX와 마찬가지로 전체 작업용 앱을 제공하기 위해로드해야합니다. 그림이나 데이터베이스 스크립트와 같은 외부 리소스를 관리하지 않는 한 Subversion과 같은 스몰 토크 버전 도구가 필요하지 않습니다. 이 또한 이미지 구축과 지속적인 통합을 자동화하는 데 도움이 될 것입니다 때문에
또한 허드슨/Jenking 통합 봐.
Svn/Git을위한 몇 가지 도구가 있지만 IMHO 몬티 첼로는 git와 매우 유사한 경험을 제공하지만 사용하기가 훨씬 쉽고 훨씬 더 통합되어 있기 때문에 여기에있는 흐름과 함께 Monticello를 사용하는 것이 훨씬 낫습니다. "스몰 토크 방식".
당신은 지정하지 않았다 스몰 토크,하지만 당신이 그것을 확실히 몬티 첼로 (그리고 물건이 복잡해진다 때 - 위에 Metacello가) Pharo를 사용하려는 경우 사용할 수 있습니다.
는 당신이뿐만 아니라 Amber에 interessted 할 수있다.
[서명을 사용하지 마십시오.] (http://stackoverflow.com/faq#signatures); FAQ에서 설명하는대로 귀하의 정보는 이미 사용자 카드의 오른쪽에 있습니다. 또한 모든 사람들이 Envy가 무엇인지 알고 있다고 가정하지 마십시오.이 개발자는 그렇지 않았던 것으로 보입니다! 이러한 문제를 해결하기위한 수정을 제안했습니다. –
"ENVY/Developer 마스터하기"Joseph Pelrine, Alan Knight, Adrian Cho. http://books.google.com/books?id=ld6E19QIMo4C – igouy