نکات کاربردی (مهم) - Developer

Asset Publisher

null نکات کاربردی (مهم)
مدت زمان یادگیری : 
انتظارات در پایان  یادگیری این بخش : 

 

۱) در زمان اجرای تامکت با انجام deploy تغییرات پروژه به فایل jar تبدیل می‌شود. نکته اینجاست که علاوه بر پنجره log مربوط به deploy که باید پیام انجام موفقیت‌آمیز deploy را نمایش دهد، پنجره لاگ تامکت ــ که ما آن را portal نامگذاری کردیم ــ  نیز باید پیام stop تامکت برای الحاق کدهای deploy شده به پروژه و start مجدد را نمایش دهد. اما برخی مواقع به دلیل اشکالی خاص، بجای پیام start مجدد، پیام خطا نمایش داده می‌شود که البته این پیام از طریق پنجره لاگ deploy قابل مشاهده نیست. بنابراین لازمست در هنگام deploy تغییرات، لاگهای تامکت نیز به دقت بررسی شود.

2021-08-09 06:27:49.539 INFO  [fileinstall-/home/user/IdeaProjects/sain-lms-application/bundles/osgi/modules][BundleStartStopLogger:49] STOPPED ir.sain.lms.webservice_1.0.0 [1208]
2021-08-09 06:27:50.446 INFO  [Refresh Thread: Equinox Container: b5aa74ba-57f9-4d50-b5d2-d1905ad60863][BundleStartStopLogger:46] STARTED ir.sain.lms.webservice_1.0.0 [1208]

۲) پس از هر مرحله توسعه کد، ابتدا تغییرات انجام شده را با عنوان مناسب commit کنید. دقت کنید که عنوان کامیت باید شامل نام task مربوطه و شرح تغییرات انجام شده در آن کامیت به زبان لاتین باشد. مثال :

LMS-168 - add filed majorId to LmsCourseTerm

سپس عملیات SourceFormat  را ـــ از طریق منوی gradle بخش formatting ماژول مربوطه ـــ انجام دهید و خطاهای گزارش شده را رفع کنید. اکنون مجددا کامیت کنید و عنوان آن را SF قرار دهید (عنوان task به اضافه SF . مثال : LMS-168 - SF).

۳) پس از آن، درخواست merge روی کد اصلی ارسال گردد.

 

۴) در صورتی که پس از ارسال درخواست merge، متوجه اشکال یا نقصی در کد خود شدید، نیازی به close آن request merge نیست و کافیست تغییرات لازم را commit کنید.

۵) درخواست merge باید با نام task مربوطه و شرح نام آن task به لاتین باشد . مثال :

LMS-168 - request department from golestan

۶) موقع ارسال mege request توجه داشته باشید که نباید این branch هیچ خطایی داشته باشد. توضیح اینکه branch اصلی (develop) که روی گیت شرکت قرار دارد - که آن را upstream می‌نامیم - مبنای کار است. هر branch جدید باید بر اساس این branch باشد و وابستگی به branchهای بعد از خود نداشته باشد. به طوریکه وقتی روی branch اصلی checkout کردیم و عملیات deploy را انجام دادیم (که طبعا هیچ خطایی نباید داشته باشیم) و سپس روی branch جدید ایجاد شده توسط شما checkout کنیم و آن را هم deploy کنیم، باز هم نباید هیچ خطایی داشته باشیم. در غیر اینصورت این کد قابل پذیرش نیست.

در صورت وجود چنین مشکلی :

- branch هایی که ایجاد کرده‌اید را به bad تغییر نام دهید . مثلا
LMS-168   ---> LMS-168-bad
LMS-169   ---> LMS-169-bad
...
- از روی نسخه اصلی (روی گیت) - که ما upstream می‌نامیم - روی برنچ develop چک اوت کنید و عملیات deploy را انجام بدید. نباید هیچ خطایی داشته باشید
-  یک برنچ جدید مثلا با نام LMS-168 بسازید و کدهای مربوط به برنچ قبلی مشکل دار (lms-168-bad)را یکی یکی، کپی و داخل این برنچ جدید paste کنید. کار این برنچ که تمام شد ، آن را deploy کنید. نباید هیچ خطایی داشته باشیم
- کامیت کنید

- عمل source Format را انجام دهید و آخرین کامیت را با عنوان SF بفرستید
- درخواست merge request بزنید.

۷) هنگامی که بر اساس نیاز، تغییری در ساختار دیتابیس  می‌دهیم، چون این کد برای اجرا روی سیستم local ما و یا سایر همکاران در شرکت حتما باید deploy شود، بنابراین به صورت اتوماتیک تغییرات روی ساختار دیتابیس لوکال هم انجام میشود و خطایی بروز نمی‌کند.
اما وقتی می‌خواهیم نسخه جدید نرم‌افزار را روی سرور مشتری ببریم، طبعا آنجا دیگر عمل deploy انجام نمی‌شود و فقط فایلهای jar را روی سرور آپلود می‌کنیم.
به همین دلیل باید به  OSGI بفهمانیم که در نسخه جدید نرم‌افزار، دیتابیس باید تغییر ساختار داشته باشه تا نرم‌افزار به درستی کار کند. اینکار از طریق upgrade process انجام می‌شود و کلاسهای مربوطه در لایه سرویس، پوشه internal ، زیر پوشه upgrade قرار می‌گیرند.

نمونه کدهای مربوط به این فرآیند در پروژه‌های شرکت وجود دارد.

طبیعتا شماره نسخه آن ماژول در کد upgrade process و کلاس UpgradeSchema افزایش خواهد یافت. باید همین شماره نسخه در فایل bnd.bnd همان ماژول نیز به روز رسانی شود . مثال :

Liferay-Require-SchemaVersion: 1.1.8

ضمنا جدول release_ دیتابیس حاوی اطلاعات مربوط به آخرین نسخه کد می‌باشد. در هنگام ارتقاء نسخه، ابتدا مقایسه شماره نسخه در این جدول با شماره نسخه bnd.bnd ماژول (فایل jar) انجام می‌شود و چنانچه نسخه کد بالاتر باشد، مراحل مربوط به upgrade process روی دیتابیس انجام می‌شود و بلافاصله نسخه دیتابیس هم با نسخه ماژول هماهنگ می‌شود. در مواردی که نیاز به تست تغییر ساختار برای دفعات دوم و سوم است، می‌توان شماره نسخه دیتابیس را به صورت دستی کاهش داد.

 

۸) نکاتی در مورد develop mode و production mode

 

۹) برای تست کدهایی مثل upgradeSchema که حتما باید ذر حالتی که تامکت به حالت  production mode  و نه Developer Mode اجرا شده باشد  باید از gogoShell استفاده کنیم.
به این منظور دو راه برای اینکار داریم. ابتدا از طریق منوی Terminalظ در اینتلیجی سعی می‌کنیم با دستور telnet به پورت 11311 لوکال هاست وصل شویم.  . لینک راهنما :
https://help.liferay.com/hc/en-us/articles/360018182911-Introduction-to-Felix-Gogo-Shell-

اما ممکنست استفاده از دستور با خطای زیر مواجه شود :
telnet: Unable to connect to remote host: Connection refused

راه دوم : از طریق مرورگر ، (تامکت در حال اجراست) از طریق Control Menu گزینه gogoShell را میزنیم
لینک راهنما :
https://help.liferay.com/hc/en-us/articles/360017897392-Gogo-Shell-Commands-for-Module-Upgrades

با استفاده از دستور upgrade:check متوجه می‌شویم که آیا دستوری برای Upgrade هست که هنوز اجرا نشده یا نه
با استفاده از دستور upgrade:executeAll  تمام دستورهای باقیمانده فوق را اجرا می‌کنیم و پیامهای آن را مشاهده می‌کنیم

لطفا قبل از ارسال کد  برای بررسی و merge، در صورت تغییر در ساختار دیتابیس، این حالت تست را هم داشته باشید.
با تشکر

 

۹) نحوه دریافت سورس کد لایفری :

git clone https://github.com/liferay/liferay-portal.git --depth 1