Hello all,

I wanted to ask what the best practices for Version control and for a good deployment workflow are. I'm currently developing a website, where I don't really need the CMS part.

Currently, I'm putting the following directories and files under version control:

- mysite directory
- themes directory with my custom theme only
- composer.json
- composer.lock

Should I put other files under version control? Please consider that I'm trying to put only those files under version control that cannot be retrieved via composer and that are specific to my website.

I then develop using the following flow:

1) Create a silverstripe project using composer.
2) Execute the installation
3) Develop on my dev machine.
4) Code will be pushed via git to a git repository (beanstalkapp.com in my case).
5) Code will be deployed to the test web server.

Step 5 is what confuses me. Ideally, my goal would be to completely remove the old deployed version and redeploy everything. So step 5 would be split up in:

1) Create backup of old working version
2) Create silverstripe project with composer. Not sure if this step is really needed, since I have composer.json and composer.lock version controlled and I could just run "composer install/update" later.
3) Execute the web installation. Since I don't use the CMS, is the web installation anyway required?
4) Copy over the files from Beanstalk
5) Copy over _ss_environment.php from old working directory to have the correct settings.
6) Execute "composer install" (or is a "composer update" enough?) to get all required dependencies.
7) Execute make and run some tests that confirm that everything is fine.

Please let me know what you think of the explained workflow. I would really appreciate some feedback.

I'm currently developing a website, where I don't really need the CMS part.

You can run 3.0 without the CMS, CMS is now it's own self contained module which you can simply not include :)

Should I put other files under version control

All those 4 items you mention should be VC. The lock file specifies the exact SHA1 version of the code you're using so people can run composer install to get the exactly same dependancies as you (vs composer update).

In prod you should always run composer install rather than updatqe to avoid getting the wrong code in production. Not sure if Beanstalk supports running composer (haven't used it myself). For my workflow I use https://github.com/dnadesign/shipistrano which is built on top of the popular Capistrano deployment system. The workflow for Shipistrano is checkout the project folder, composer install to grab latest assets and rsync up to the target server (prod, staging or UAT) which works well.

If you only have FTP for deployment you're outta luck for most solutions and composer support.

Regarding your other questions:

All the installer does is setup the .htaccess file, _config.php and check requirements. All of which you don't need to every deploy so leave the _ss_environment.php on your test box and just copy up your new files and run dev/build (you'll also need to copy any assets you need to test).

Thanks Willr for your answer.

All those 4 items you mention should be VC.

Are there actually also other files I should put under version control? E.g. behat.yml, build.xml, web.config and so on.
I am asking this because if I run

composer --no-dev --prefer-source --no-interaction create-project silverstripe/installer 

then I end up with all this files in my project root dir, which are not created if I just copy the composer.json and composer.lock files over and run

composer install 

Not sure if Beanstalk supports running composer
Beanstalk doesn't support running composer, but it supports running shell scripts via SSH so you can do almost everything...with some scripting.;)

The workflow for Shipistrano is checkout the project folder
Does it mean that you put the entire project root folder under version control? What about the framework directory do you put it under version control?

Does it mean that you put the entire project root folder under version control? What about the framework directory do you put it under version control?

The whole project is under VC apart from dependancies such as framework. Since this is managed by composer, it doesn't need to be in your Git repo.

I have the same question as the topic creator. In my current case, the only needed files for version control are the 4 already described documents:

- mysite directory
- themes directory with my custom theme only
- composer.json
- composer.lock

In the install SilverStripe via composer guide it says, that the preferred installation method is "composer install" because it will look after your composer.lock file. But my problem is the following:

When i deploy my 4 files into a folder on my webserver and call composer install, i get the framework, the cms and the modules. but all the files in the root folder of the project (Web.config, index.php and so on) are not added.

Then i tested the "composer create-project silverstripe/installer ./test" command, which created these files and added all the needed basic things like framework and cms including the root files. But then i have to copy or clone my repository content inside the root folder afterwards, which is not really cool in my opinion because the approach is flipped.

When i create the folder first, add the files from git and then run the installer, the installation fails because the folder already exists and is not empty.

So my question is: What do i have to set under version control and how can i install SilverStripe with my specific files in another environment like my live webserver without adding everything to git?

The code of my composer.json looks like:

{
    "require": {
        "ajshort/silverstripe-gridfieldextensions": "dev-master",
        "silverstripe/multivaluefield": "dev-master",
        "sheadawson/silverstripe-blocks": "dev-master"
    }
}

Thanks in advance.

Regards,
Pascal

Just to add my current workflow into this (in case it helps).

1. On dev machine pull down the silverstripe installer from github.
2. Customise and add relevent modules to the composer.json file.
3. Setup .gitignore to include additional dependencies I have added.
4. Run composer install (as I have installed composer system wide, otherwise I would pull down composer and add it to the project root).
5. Once everything is pulled down, setup db and config
6. Setup a new project in my VCS (currently BitBucket).
7. Run #git init followed by git remote add origin url/to/git/repo.
8. #git push origin master.

Once I am ready to deploy, I usually use annotated tags in Git. So I run #git tag -a 1.0-b1

This creates an annotated tag, which I then push to the repo.

I have git installed on my servers, and then just ssh in and run #git fetch --tags and then #git checkout 1.0-b1

Then run #composer install if I have updated dependencies.

Think that is it!

@rootix, composer won't pull down the files out of your repo. It simply deals with dependencies. You would have to deploy your project files with your web.config, composer.json, composer.lock, themes, etc first.

Then use composer to pull down the dependencies.

Hope that makes sense?

Cheers,

Mo

Thanks for the insight, Mo.

I understand that composer does not get things out of my repo. The main question is: When i develop a website on my local machine, which files of the whole cms (Installed with installer, framework, cms and some needed modules there) do i have to set under version and which files not. Obviously the module folders are not necessary because i can reinstall them with composer install when deploying to the live webserver.

But what is with the framework, cms, themes/simple folders? And the root files like index.php and so on? Do i have to commit them into my repository?

The only files I commit are:

mysite
themes (with any sub folders)
.gitignore
composer.json
composer.lock (though this depends on the project and whi is working on it, if it is just me, I don't usually bother).

Framework is the Silverstripe framework libraries. This is required for you to work with Silverstripe.
CMS adds additional content management libraries (you need this if you want to create content managed websites).
Themes/simple is the default theme shipped with silverstripe

if you want to create new themes, you add them as new folders to the themes directory.

Framework and CMS can be added to composer and managed via the composer.json, so they do not need to be in your repo.

Only add themes/simple if you want to use that theme in your project.

Not sure if that makes sense? Is that what you needed to know?

Cheers,

Mo