diff --git a/public/blog/website_workflow/index.html b/public/blog/website_workflow/index.html index a22ee6e..d8c882c 100644 --- a/public/blog/website_workflow/index.html +++ b/public/blog/website_workflow/index.html @@ -208,7 +208,7 @@ , "url" : "https:\/\/antiz.fr\/blog\/website_workflow\/", - "wordCount" : "447", + "wordCount" : "441", "genre" : [ ], "keywords" : [ ] } @@ -437,11 +437,11 @@

CI

The test job spawns an Alpine Linux container which automatically runs a bunch of tests/linters against the relevant files of the repository, to make sure the changes I made are correctly written/syntaxed. See a run of the test job here.

CD

-

Once both of the above CI jobs succeeded (meaning the website has been successfully built and pushed to the dev branch of the repository, and the tests went through without any error), I launch a job on my Jenkins server targeting the dev branch:

+

Once both of the above CI jobs succeeded (meaning the website has been successfully built and pushed to the dev branch of the repository, and the tests went through without any error), I launch a job on my Jenkins server targeting the dev environment:

alt_text

-

This Jenkins job runs a simple Ansible playbook under the hood (see that playbook here) that aims to update the website’s sources on the environment targeted by the Jenkins job against the related GitHub branch (dev branch –> development environment, main branch –> production environment):

+

This Jenkins job runs a simple Ansible playbook under the hood (see that playbook here) that aims to update the website’s sources on the targeted environment against the related GitHub branch (dev branch –> development environment, main branch –> production environment):

alt_text

-

I can then review what my changes look like on my development environment (which is identical to my production environment so I’m guaranteed that what I’m seeing on my development environment is exactly what it will look like once pushed to my production environment).

+

I can then review what my changes on my development environment (which is identical to my production environment so I’m guaranteed that what I’m seeing on my development environment is exactly what it will look like once pushed to my production environment).

Once the changes have been reviewed and declared “ready” to go to production, the only thing I need to do is to merge the changes to the main branch on the GitHub repository (by “accepting” the pending merge request) and relaunch my Jenkins job, targeting the “prod” environment this time, so the changes are pushed against the main branch to the VPS which hosts this website:

alt_text

This workflow aims to evolve and be improved over time but it’s a good example of a simple; yet effective, flexible and reliable automated workflow with CI/CD you can use to manage your projects! 😁