Jump to:

23483 Posts in 18965 Topics by 2878 members

General Questions

SilverStripe Forums » General Questions » Version control and deployment workflow

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Page: 1
Go to End
Author Topic: 1214 Views
  • finrod
    Avatar
    Community Member
    5 Posts

    Version control and deployment workflow Link to this post

    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.

  • Willr
    Avatar
    Forum Moderator
    5508 Posts

    Re: Version control and deployment workflow Link to this post

    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).

  • finrod
    Avatar
    Community Member
    5 Posts

    Re: Version control and deployment workflow Link to this post

    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?

  • Willr
    Avatar
    Forum Moderator
    5508 Posts

    Re: Version control and deployment workflow Link to this post

    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.

  • rootix
    Avatar
    Community Member
    2 Posts

    Re: Version control and deployment workflow Link to this post

    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

  • Mo
    Avatar
    Community Member
    508 Posts

    Re: Version control and deployment workflow Link to this post

    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

  • rootix
    Avatar
    Community Member
    2 Posts

    Re: Version control and deployment workflow Link to this post

    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?

  • Mo
    Avatar
    Community Member
    508 Posts

    Re: Version control and deployment workflow Link to this post

    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

    1214 Views
Page: 1
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.