CPANEL/MAIN SITE - FEATURE - Automatic deployment to the development server

[nguillaumin]

I've been working on automating the deployment of new code to the development server. The idea is that Shippable will run the tests as usual, and if they pass the updated code is automatically copied to the development server to make it available for users to play with.

I've got something working, but to enable it it means we'd have to change our workflow a little bit. We obviously don't want to copy each & every change to the dev server, only changes that have been tested & validated and properly merged. The way to do that is to create a new branch like development. Everything that gets merged there gets automatically deployed. It's basically replacing the per-month branches we used to have (January-release, Februrary-release, etc.) with a single branch development on which we always merge.

That allows us to keep our current workflow of using new branches for new features (and even mini-projects), and where they're ready we just merge then on development and that's it. To do a production release, we would merge development into master, and then deploy manually (at least for now).

The big benefit is less manual operations (with the risk of error, as we've seen a few times it's easy to miss a file) and it also makes the changes available quicker to the users for testing.

Let me know what you think @stgraveyard @stsilversurfer ?

[stgraveyard]

I love the idea Nico. And the DEVELOPMENT branch can be considered a release. And when we feel it is ready, we merge and do a manual prod update. After that we create a new 'DEVELOPMENT' branch?

When can we start with this way of working?

[nguillaumin]

We wouldn't create a new development branch, we would just continue using it:

                                                      feature #2              new feature #3 after release
                    feature #1    +-----+---+--+        +----+               +---+
                                 /              \      /      \             /     \
                                /                \    /        \           /       \
development              +-----+------------------+--+----------+--+------+---------+--...
                        /                                           \
                       /                                             \
master         -------+-----------------------------------------------+----------------...
                                                               release (December)

I think to start with that we would need to merge everything to master, do a release, remove any other branch, and create development from master. So perhaps just after we release the dump section?

[stsilversurfer]

This is super! I like it a lot. :-)

[stgraveyard]

I like this idea. I will finish up the release in the weekend, than I leave the creation of the branches to you @nguillaumin and will follow ...

[nguillaumin]

I've created the development branch. Anything committed to that will be pushed to DEV. If you look at Shippable you'll see this:

I've documented it on the wiki

@stgraveyard we should protect the branch to ensure any change to it goes via a merge request rather than a direct commit. Only you can do it as you are the repository owner.

• Go to the settings on the top right
• Choose "Branches" on the left
• Under "Branch protection rules" click "Add rule"
• Apply rule to: development
• You can have a look at the options there. The most flexible is to not tick anything, but we could also choose to have at least 1 approved review for each change, or ensure that the Shippable build pass succesfully.
• I would suggest ticking "Include administrators" so that you can't bypass the protection yourself :wink:

From now on all pull request should have development as a target...

Cheers!

[stgraveyard]

This is taking it to a whole new level! Thanks a lot, let's hope I still manage to merge anything, as this is pure rocketscience to me (even with the awesome wiki update) :-D

This is what I have set up :

Let's test this in the days to come. And thanks a lot for this one Nico.

@stsilversurfer , this is an important read! ;-)

[nguillaumin]

Cool, let's see how we go with this...

[stgraveyard]

Seems to be working like a charm, no? I'm closing this one. Thanks so much for this. It is a fantastic feature for the DB team.

[nguillaumin]

I think I still need to improve a few things:

• Delete files that have been deleted in Git. It looks like this was never done so there were a ton of old files on the server. I should be able to configure the sync to do that
• Find a way to run the DB updates automatically so that we don't have to manually visit the DB update page after deployment.

I'll reopen it to make sure I don't forget.

[stgraveyard]

You are pure gold!

[nguillaumin]

I think we're good with that now.

Any interest in doing that to prod too, with the master branch?

[stgraveyard]

Yes very much!

[stgraveyard]

@nguillaumin Would you perhaps be able to set up this feature in the days to come? (after the holidays or so?). @Marcer75 has been asking to use the dump section on prod...

[nguillaumin]

I think we're all good for automatic deployment on production too. Any pull request to the master branch will be deployed automatically to prod.

@stgraveyard could you protect the master branch the same way you did with development (see comments above)? Thanks!

[stgraveyard]

@nguillaumin Branch protection to master has been added.

[stgraveyard]

@nguillaumin So how does this work now. I see we still have a development branch, yet prod is updated. So we merge the dev branch to master, prod gets updated, and than we create a new development branch? Or how do you do it?

[nguillaumin]

Basically:

• Whatever is on master is on the prod server
• Whatever is on development is on the dev server

Any change to any of these branches will trigger the deployment to the right server.

So:

• Yes, we merge the dev branch to master to update prod
• We can keep the development branch, we don't need to create a new one (you can keep a branch after it's merged and continue to us it)