I know I’ve been neglecting this blog lately, that’s largely to do with spending so much time building PYDIEM and the Hostery.
I have however as part of the Hack.Summit() hack.pledge(), I have committed to being a mentor to a developer in 2015 (only for an hour, but I intend to do much more).
As part of that larger commitment and on top of the software developer I am already guiding as part of our team at PYDIEM; I intend to start giving back more to the community and encouraging better programming, computer science and IT decision making from the grass-roots.. that means more presentations and talks at local developer meetups (look out Sydney Python!) and much more blogging of developer news, tips and other things of geek interest here.
So, you’ve found the various howtos and documentation around the ‘net for getting your first Amazon Elastic Beanstalk application up and running. You’ve downloaded the AWS-ElasticBeanstalk command line tools and you happily pull down your latest code and deploy with “git aws.push” – but now it’s time to allow other members of your team to deploy code to your shiny new Beanstalk environment.
For over four hundred years the profession of journalism has been one to hold in high regard; the reporter always on the hunt to uncover the truth, scoup the story first or get the best photographic or multimedia recording. Images of the romantic image of the 1920s news paper man or second world war news reels to the popular culture ideals of a cocaine snorting; moustache donning anchor man on the evening TV news all a layer of romance to that fundamental quest – the quest for fact, truth and public interest.
The answer is simple – your team wants to build more reliable software; more effectively.
One of the biggest issues facing any development team of more than one developer is ensuring that any changes being made do not break other parts of the software you are collaborating on. While this is often mitigated by developers working on separate parts of the system based on their area of expertise, in the golden age of object oriented, re-usable code the impact of any changes has become harder to track and test.
The initial benefit of a bare implementation of a basic CI system provides an automated approach to something that your developers are probably doing manually already. Every time a branch is merged back into your main branch (a future article will explore sensible approaches to branching and merging) CI kicks in; prepares a test environment and checks the main branch into it ready for testing – in itself an incredibly useful start.
It’s been a while; but I’ve got some interesting projects on right now which I feel will provide inspiration for writing again, and I was sick of having a “coming soon” page up as the only content under my domain. I do still plan to dig up some old content that is still being requested (it’s amazing to watch the 404s in the error log looking for articles I wrote years ago!).
Stay tuned for more shortly!