I am working on a small app and I have a typical MVC design structure. Thus, all my front-end is located inside a special directory that is separated from actual back-end code and DB scripts. I use heroku to deploy from github. But recently I had a designer to join in and I would like to give designed ability to push into ONLY designer related folder on my github project. Is it possible to do so? If not, is it possible to organize some sort of abstraction between different folders in heroku?
Thanks!
Related
I have been writing an E-shop project for a customer and now I have signed a new similar contract with another customer. I was wondering what would be the best practice to continue the first project while staring the second so that the reusability is at maximum?
One way would be to change the first project to read all menu items, slider pictures, ... from the database so that I can deliver the same project to both customers with different databases. The benefit of this approach is that I have to manage only one project, but it leads me to gradually write a CMS, which is a time-consuming task.
The other solution would be to use Git. For example, I would fork the base project into two different projects. If the functionality I am writing is the base one, then I would push it into the base project; otherwise, I push it into the appropriate forked project.
Which one is a better approach in your opinion? Or you guys have any better idea?
Cheers,
Habib
There are a few things that need to be considered.
First of all, This project as you said has the capability to be sold more. So, you must think about how much is possible to make it dynamic via Configuration files, Hooks & Plugins to make the modification to the functionalities of the project through that. I know you have considered this already.
Second, Using a Core Repository and different forks for customization. (It's a great idea but needs proper discipline, workflow and manpower to make sure everything is fine-tuned and works properly )
It's highly recommended to make your application cloud-native and provide proper UAT/QAT Environment for test before launching on the production, And also implementing Test cases to be checked within the Git and CI/CD pipelines in order to prevent issues in the merge process.
I'm not certain about what you want, but if you want to develop an enterprise project that contains many features such as wallet, tracking, payment,... I think you can implement each service as a microservice and integrate all of them.
About git, I think it's better just for handling the source code and you had better use git module for handling microservice and just using branches for developing process
I have finally found some solutions that I would like to share with you guys. Let's divide differences into 2 big categories of data differences and code differences:
Differences in data
If the database in each project is different (e.g., the product has some features in one project and some other features in another project), then the best solution is to use NoSQLs such as MongoDB. In the first place, NoSQLs are designated to support databases that don't have well-defined data structures, and you don't know what features you may add to each entity at present or in the future. It completely applies to my scenario that each shop may have a different data structure. However, since my project is based on Laravel and it does not have built-in support for MongoDB, I have decided to design some key-value tables that haven't been so bad so far.
Differences in the code
Regarding differences in the code, I would definitely suggest branches in Git and other functionalities provided by Git repositories such as Gitlab repository mirroring. Each feature has a different branch in my code, and I can provide each customer with different functionalities by merging those branches I want to deliver to the customer.
All in all, you may take as much business logic as you can into the database since changing it in the future is more straightforward. On the other hand, you'd better keep themes in the code because every customer likes a different theme, and changing them in the code is easier than taking them to the database.
What is the preferred solution for Exrin project layout when adding a database?
The sample Tesla app had a separate project for the Services and another separate app for the Repository. With the removal of both of those projects in the latest template, it makes the most sense for it to go within the Logic project, but I'm curious if the author had a different preferred implementation.
The Tesla Sample project is designed for a very large app, and Service and Repository don't need to be separated out into a separate project, they can all be referenced directly in the logic app, as per this diagram.
This is the project setup, I now recommend for most projects.
I Develop one website using magento. How to i Publish on server? If asp.net after publishing
codes are converted into dll . but here magento How It work? How i configure my own website?
Thanks in Advance...
There are a number of ways to do this. From simplest to most complex:
Simple zip and unpack on the server. Migrate databases with mysqldumps.
Push files with an FTP program. Preferably one with a compare viewer, such as Beyond Compare
If you utilize a QA environment or a staging site on the same box or a local server you can utilize rsync to push changes from one directory to another.
Create a source-control repository and use your production site root as a checkout of your Magento application (probably your best bet for ease of use).
Utilize source-control but deploy with a build tool such as Apache Ant.
Implement continuous integration with a tool such as Capistrano, Hudson/Jenkins, or CruiseControl
You really want to be using source control anyhow - so deploying straight from SVN/Git/Hg or another tool makes the most sense as it is easiest to manage and requires very little effort on your part. Making your repository publicly accessible can be as easy as using a free service such as GitHub or Beanstalkapp. Paid levels give you private repos or more than one user.
Continuous integration will be your best bet for rapid deployment on a site that is changing quickly and many deployments happen daily. Some comparison of tools:
http://en.wikipedia.org/wiki/Comparison_of_Continuous_Integration_Software
I hope that helps. I have deployed Magento using all of the above methods. There really is no elegant way to push databases around outside of using upgrade scripts in local modules. You can use tools like Maatkit to diff tables or in some extreme situations I've seen developers alternate between qa and production environments using Magento's built-in table prefixes.
I've been using Mercurial for a bunch of standalone projects. But now I'm looking at converting a subversion repository to Mercurial thats a lot more busy / complicated.
Given about 40 Library projects and about 20 Applications ( various web / console / wpf, etc) or so. Various apps make use of various Libs. All of this is structured under 1 trunk in subversion. So there's a directory where all the libs live, and a directory where all the apps live. Very easy to find and reference the libs when creating a new Visual Studio Projects.
simplified....
--trunk-|-- libs
|-- apps
Now moving to mercurial, this is less ideal, it seems the way to handle this is with 1 repository for each app? and sub repositories per each lib you want to use?
--app repository-|-- libs
|-- app
Is this right?
If so, when starting a new application in visual studio and you want to add various libs, whats the best/most efficient way to go about it?
I'm getting the feeling the initial setup is a bit painful? As opposed to the subversion layout where effectively you don't really have to do anything other than reference the library in your visual studio project.
So, hence this question, wanting to know a good directory structure, and how to quickly setup a new project using this structure.
Ideally, and this is going to be based on my own opinion and experience in working with larger, distinct applications, but with dependencies, you want to have a repository per distinct, unrelated project, and keep related, possibly dependent projects within the same repo. I'm not a big fan of Subrepositories, but that might just be to lack of exposure.
The reason for this is that you should want to version related projects together as changing one may affect the other. In reality, anything that can be pulled into a single solution and have project references, you definitely want to keep together.
Now, there are some exceptions where you may have a library project that you can't necessarily have as part of a solution, but is a reference for a set of projects. This is where I'd keep a lib folder versioned along side the rest of my applications in the same repo, but the lib folder holds pre-build assemblies. It can also hold 3rd party vendor assemblies as well. This is also important to be versioned along with the project that uses them as you can treat a library update for the main project as a minor release.
For other projects that are truly independent, create another repository for it, as it will have its own version life and you do not want changes to it to affect the graph of changes for your other, completely unrelated projects.
Example layout with several related projects and lib folder:
[-] Big Product Repo
--[-] Big Product 1
----[+] Dal
----[+] Services
----[-] Web
------[+] Controllers
------[+] Models
------[+] Views
--[+] Big Product 2
--[-] lib
----[+] iTextSharp
----[+] nHibernate
Example layout with another unrelated project in it (for sake of argument, a Windows services project):
[-] Small Product Repo
--[-] Windows Services
----[+] Emailer
----[+] Task Runner
In reality, though, your folder structure isn't as important as making sure projects that are being treated as one logical unit (a product) are kept together to ensure control over what is built and released. That is my definition of what a repository should contain and what I use to think about how to split things up if there's more than one versionable product.
I am wondering what is the best way to use workspaces in visual studio. We have 150+ webservices that are all part of the same team project $/MyTeamProject without being related at all. The reason for them all being part of the same team project as they are all maintained by the same group of people within our organization.
Each webservice has the following structure
$/MyTeamProject/WebService1
$/MyTeamProject/WebService1/Main
$/MyTeamProject/WebService1/Release/1.0
$/MyTeamProject/WebService1/Release/1.1
$/MyTeamProject/WebService2
$/MyTeamProject/WebService2/Main
... etc.
I am wondering what is the proper way to use workspaces with this setup as currently there is only mapping for the teamproject so all my webservices are part of the same workspace. Should I create mapping for the main branch and for each release branch as a separate workspace or should I map each webservice to its own workspace such as $/MyTeamProject/WebService1?
Any help would be appreciated.
I can't put each of the webservices as its own teamproject as the tfs is being shared between several groups with the same magnitude of projects and therefore we are limited by our own teamproject for all of the webservices.
You said that the webservices was not related at all. I then assume that they are released separately.
I can't see any reason to use multiple workspaces in your scenario.
I suggest that you remove the mapping from the top level project "MyTeamProject". Then you have flexibility to map the subfolders to whatever local folder you want.
If you have one workspace per webservice then you will get 150*#releases workspaces. This will get really hard to manage for build versions, labelling etc. Fewer workspaces will mean less builds to manage.
I would recommend having a workspace per release. Generally you would probably only be working on one release at a time and this will allow you to manage all code for a single release effectively. Also you can then map your workspaces on the client into a more logical structure as you allude to in the question.
For example
\Projects\MyTeamProject\Main\WebService1
\Projects\MyTeamProject\Main\WebService2 ...
\Projects\MyTeamProject\Release1.0\WebService1
\Projects\MyTeamProject\Release1.0\WebService2 ...
\Projects\MyTeamProject\Release1.1\WebService1
\Projects\MyTeamProject\Release1.1\WebService2 ...
etc